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I .  INTRODUCTION 


A .  BACKGROUND 

Although  there  is  a  CM  policy  in  place  at  the  Naval  Air 
Warfare  Center  Training  Systems  Division  (NAWCTSD) ,  it  has  not 
been  implemented  in  a  manner  that  standardizes  CM  across  all 
weapon  platforms  and  programs.  Furthermore,  CM  requirements 
are  not  interpreted  the  same  by  all  personnel  required  to 
implement  CM  for  systems  acquisition  or  during  the  systems' 
life-cycle  support  phase.  It  is  highly  desirable  to  establish 
the  minimum  acceptable  CM  standards  that  all  programs  must 
meet . 

It  is  anticipated  that  implementation  of  an  effective 
acquisition  CM  policy  at  NAWCTSD  will  provide  a  base  for  the 
development  and  implementation  of  an  effective  CM  policy  for 
the  life-cycle  of  acquired  systems.  Although  life-cycle  CM 
will  be  discussed  in  this  thesis,  the  main  thrust  will  be  the 
determination  of  an  effective  acquisition  CM  policy  for 
NAWCTSD . 

The  present  CM  policy  at  NAWCTSD  is  governed  by 
NAVTRASYSCENINST  4130.3,  dated  29  September  1993.  It  is 
presently  under  review  for  revision  and  will  include 
information  derived  from  this  thesis  as  part  of  a  planned 
]f0vision  scheduled  to  be  performed  annually .  The  instruction 
title  will  be  changed  to  NAWCTSDINST  4130. _M  to  reflect  the 
new  organizational  title.  NAWCTSD  was  previously  the  Naval 
Training  Systems  Center  (NTSC) .  NTSC  became  NAWCTSD  after  the 
present  NTSCINST  4130.3  was  implemented.  In  this  thesis  the 
instruction  will  be  referred  to  as  the  NAWCTSD  4130. _M 
instruction  to  reflect  the  new  correct  name  for  the  updated 
instruction. 

Competency  1.3.2,  the  Program  Support  Competency,  is  the 
lead  organization  for  configuration  management  at  NAWCTSD.  It 
is  responsible  for  establishing  CM  policy  and  for  insuring 
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that  consistent  and  acceptable  CM  is  practiced  in  all  programs 
under  the  cognizance  of  NAWCTSD.  Competency  3.0  is  updating 
and  modifying  the  NAWCTSD  CM  instruction  as  an  assist  task  to 
Competency  1.3.2.  The  NAWCTSD  instruction  is  a  derivative  of 
the  NAVAIRINST  4130. 1C  dated  31  January  1992.  The 
implementation  of  NAWCTSDINST  4130. _M  will  encompass  overall 
CM  policy  and  promulgate  instructions  and  other  directives  and 
guides  to  all  competencies  required  to  implement  CM  policy. 

Competencies  1.3.2  and  3.0  are  not  the  only  competencies 
with  an  interest  in  CM  policy  at  NAWCTSD.  Several  other 
competencies  are  responsible  for  implementing  CM  policy  either 
in  conjunction  with  an  acquisition  (for  new  systems  or 
upgrades  to  existing  systems)  or  in  conjunction  with  ongoing 
Life-Cycle  Support  (LCS) .  Outlying  field  activities,  called 
In-service  Engineering  Offices  (ISEOs) ,  provide  trainer  system 
engineering  support  (modification)  for  hardware,  software,  and 
technical  documentation  as  well  as  a  variety  of  other  trainer 
and  training  system  support  functions. 

Competency  4.0,  the  Engineering  Competency,  and  the  ISEOs 
are  responsible  for  acquisition  support  of  training  systems  as 
well  as  hardware,  software,  and  documentation  status.  They 
are  also  responsible  for  implementation  of  automated  or  other 
CM  and  Configuration  Status  Accounting  (CSA)  functions  and 
systems  in  support  of  systems  acquisitions  efforts  and  their 
fielded  systems. 

Competency  3.0,  the  Logistics  Competency,  performs  many 
support  functions  including  support  for  systems  acquisition 
efforts  and  is  intimately  involved  in  ongoing  CM  issues 
concerning  "fielded"  systems.  "Fielded"  in  this  context, 
implies  that  the  system  is  no  longer  under  the  direct 
cognizance  of  one  of  the  acquisition  Project  Managers  (PJMs) 
as  an  acquisition  oriented  project.  PJMs  retain  cognizance 
over  the  system  for  the  life  of  the  system,  but  the  emphasis 
for  system  support  changes  from  acquisition  to  LCS  when  the 
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system  is  fielded.  Within  Competency  3.0,  the  Integrated 
Logistics  Support  Manager  (ILSM) ,  one  of  the  Competency  1.0. X 
competency  managers,  will  determine  general  CM  requirements, 
CM  data  requirements,  and  CM  audit  requirements  in 
consultation  with  the  Project  Manager  (PJM) . 

NAWCTSD  procures  and  supports  systems  which  provide 
unique  CM  challenges.  Most  of  the  acquired  and  supported 
systems  are  complex  state-of-the-art  systems  and  are  acquired 
in  small  numbers.  Maintenance  support  is  provided  almost 
exclusively  by  contractors .  Technical  documentation  accuracy 
and  system  concurrency  with  weapon  systems  or  other  platforms 
is  crucial  and  will  cover  a  span  of  many  years  dependent  upon 
the  weapon  system.  CM  plays  a  major  role  in  assuring  that 
system  changes  are  properly  documented,  that  hardware  and 
software  changes  are  traceable  to  requirements,  and  that 
baselines  are  accurately  represented  in  data  management 
systems.  Simply  put,  all  documentation  for  both  hardware  and 
software  must  accurately  reflect  the  current  system 
configuration . 

Systems  acquired  and  supported  by  NAWCTSD  are  widely 
dispersed  throughout  the  continental  United  States,  Hawaii, 
Alaska,  and  in  many  foreign  countries.  Additionally,  NAWCTSD 
serves  many  customers  such  as  the  surface,  sub- surface,  and 
aviation  communities  within  the  Navy  as  well  as  the  Army,  Air 
Force,  Marines,  and  other  Federal  agencies. 

A  memorandum  released  by  the  Secretary  of  Defense, 
William  Perry  [Ref.  1]  ,  states  that  unless  waivered,  military 
specifications  and  standards  will  not  be  applied  to  the 
acquisition  of  new  weapon  systems .  This  has  introduced  an 
element  of  question  in  the  implementation  of  CM  based  on  MIL- 
STD-973  and  other  standards.  If  military  standards  are  not  to 
be  used  in  the  development  of  new  systems,  then  the 
implementation  of  CM  in  a  standardized  fashion  using  MIL-STD- 
973 ,  may  not  be  a  goal  of  NAWCTSD  as  a  matter  of  policy . 
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It  may  be  that  NAWCTSD  will  rely  on  industry  standards 
defined  in  individual  contract  definitions  to  implement  CM. 
This  question  will  be  more  thoroughly  discussed  in  Chapter  V, 
Analysis  and  Interpretation  of  Data. 

B.  RESEARCH  AND  SUBSIDIARY  QUESTIONS 

This  thesis  will  address  the  following  research  question: 

What  should  be  the  essential  elements  of  a  configuration 
management  (CM)  policy  for  NAWCTSD  acquisitions  and  how 
might  this  policy  be  implemented? 

The  following  subsidiary  questions  will  further  define 
the  problem  and  lead  to  a  more  complete  analysis: 

What  are  the  essential  elements  of  CM  policy  and  what  are 
the  requirements  established  by  DoN,  DoD,  and  other 
Federal  Government  regulations? 

What  are  the  basic  components  of  CM  policies  that  exist 
for  similar  Government  organizations  and  industry  firms? 

What  are  the  significant  problems  and  issues  associated 
with  establishing  a  CM  policy  that  is  unique  to  NAWCTSD 
and  how  might  these  problems  and  issues  be  resolved? 

These  subsidiary  questions  will  be  further  subdivided  into 
sub- subsidiary  questions  as  necessary  to  completely  answer 
each  element  identified.  This  approach  to  problem  solving, 
known  as  the  dendritic  approach  [Ref.  2,  p.  14-6],  is 
diagrammed  in  Appendix  A.  The  reader  is  invited  to  refer  to 
Appendix  A  as  needed  to  gain  a  picture  of  the  complete  problem 
description  and  proposed  solution. 
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C.  PROBLEM  DEFINITION 

The  major  problem  is  that  CM  is  neither  uniformly  nor 
effectively  applied  in  the  acquisition  and  life-cycle  support 
of  training  devices  and  equipment  procured  or  accepted  for 
support  after  procurement  by  NAWCTSD.  The  magnitude  of  this 
problem  is  reflected  in  the  size  of  the  inventory  supported  by 
NAWCTSD,  which  is  approximately  2,500  trainers  and  training 
systems  valued  at  approximately  $3.5B  located  at  289 
individual  fleet  and  training  units. 

In  an  era  of  continuous  downsizing  of  the  armed  forces, 
it  is  crucial  that  simulation  systems  and  trainers  be  properly 
maintained  and  that  the  configuration  of  those  systems 
accurately  reflect  the  systems  they  support.  CM,  properly 
executed,  can  save  potentially  billions  of  Operation  and 
Maintenance  (O&M)  dollars  by  improving  system  software  and 
hardware  maintenance  and  by  reducing  the  need  for  operational 
equipment  and  personnel  required  to  be  used  in  training 
scenarios . 

In  some  cases,  an  adequate  CM  system  has  not  been 
established  during  acquisition.  This  can  be  problematic 
during  the  acquisition  phase  and  may  carry  over  into  the 
operational  system  for  its  entire  life-cycle.  It  is  important 
that  the  process  of  CM  be  started  early  in  the  acquisition 
phase  in  order  to  assure  that  system  baselines  are  accurate 
and  fully  documented  at  the  time  the  system  is  accepted  by 
NAWCTSD  and  the  user.  Such  a  CM  system  should  be  in  place  and 
workable  prior  to  acceptance  of  the  system  by  the  Government . 

The  level  (system,  sub-system,  sub-sub- system.  ..) , 
methodology  (automated,  manual,  combination  of  both),  and 
systems  (training  devices,  technical  documentation)  on  which 
CM  is  to  be  performed  is  not  as  clearly  defined  in  existing 
instructions  and  guidelines  as  some  personnel  would  prefer. 

Competency  1.3.2  is  responsible  for  overall  CM  policy 


5 


(writing  instructions,  defining  scope,  defining  methodology, 
etc.) .  Other  competencies  within  NAWCTSD  are  responsible  for 
implementing  that  policy.  It  is  not  clear,  therefore,  what 
role  each  of  the  implementing  competencies,  including 
acquisition  competencies,  will  play  in  establishing  or 
actually  performing  CM  on  systems  and  technical  documentation. 
Nor  is  it  clear  what  the  needs  of  each  of  those  competencies 
are  with  respect  to  CM.  The  role  of  contractors  and  their 
performance  of  CM  during  the  system' s  operational  phase  should 
also  be  clearly  defined. 

These  problems,  in  the  aggregate,  have  prevented  the 
effective  implementation  of  CM  across  the  broad  spectrum  of 
NAWCTSD  supported  and  acquired  devices.  It  is  evident  that  CM 
is  being  performed,  but  the  evidence  indicates  that  it  is 
spotty,  that  there  is  no  unified  data  management  regarding 
reporting  systems,  that  different  competencies  interpret  the 
level  to  which  CM  is  to  be  performed  differently.  This  may  be 
caused  by  the  diverse  customer  base  and  because  NAWCTSD  is 
managing  many  unique  and  totally  different  configuration 
items.  These  problems  result  in  inefficiencies  in  the  overall 
system. 

It  should  be  noted  that  differences  in  the  method  of 
performing  CM  and  the  level  to  which  it  is  to  be  performed  may 
differ  between  training  systems  and  their  respective 
communities.  The  core  CM  effort  at  NAWCTSD  needs  to  be 
standardized  and  a  standard  approach  to  accomplishing  CM 
across  all  supported  communities  and  devices  should  be 
established.  In  this  context  "core"  means  CM  procedures  and 
methods  used  by  NAWCTSD  in  support  of  oversight  CM  functions 
that  support  all  Cognizance  2"0"  systems.  An  example  of  this 
would  be  the  functions  of  the  NAWCTSD  Trainer  Engineering 
Change  Control  Board  (TECCB)  and  the  central  status  accounting 
system  used  to  document  multiple  configuration  items  which 
span  all  systems  supported  by  NAWCTSD. 
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It  is  evident  that  different  competencies  perform  the 
functions  of  CM  differently.  Different  CM  systems  are  being 
used  (and  this  will  likely  continue  to  be  the  case  for  the 
reasons  stated  in  the  previous  paragraph) .  Some  of  the 
different  types  of  physical  systems  include  fully  automated 
(mainframe,  mini -computer,  or  PC)  ,  semi -automated,  semi-manual 
depending  upon  the  emphasis,  manual,  or  partially  implemented 
systems  that  simply  document  the  system  or  item  according  to 
device  number,  nomenclature,  and  serial  number  (essentially  no 
more  than  inventory  maintenance) .  There  are  also  different 
technical  approaches  to  CM  based  on  the  individual  program  or 
system.  It  is  not  the  difference  in  systems  that  is 
important,  it  is  the  difference  in  the  methodology,  level,  and 
types  of  reporting  and  documentation  that  must  be  studied  and, 
if  necessary,  changed  to  improve  the  overall  accomplishment  of 
NAWCTSD  core  CM  in  a  standardized  fashion  and  of  approaching 
development  of  CM  systems  in  support  of  different  platforms, 
weapon  systems,  and  communities  served  by  NAWCTSD. 

Records  which  document  baselines  and  configurations, 
whether  digital  or  hard  copy,  are  not  standardized,  are 
difficult  to  understand  across  all  platforms,  and  do  not  share 
common  data  elements.  Traceability  from  requirements  to 
system  configuration  (including  the  configuration  that  results 
after  modification  to  the  system)  is,  in  some  cases,  spotty  or 
non-existent  and  is  not  in  a  standardized  format.  Digital 
information  cannot  be  shared  universally. 

A  standardized  approach  to  CM  will  make  reporting  simpler 
and  will  facilitate  better  communications  across  Service  or 
agency  borders.  CM,  if  not  properly  performed  may  result  in 
situations  where  a  weapon  platform  may  not  be  accurately 
modeled  by  the  simulation  system.  In  those  cases  training  can 
have  a  detrimental  effect.  The  problem  is  mitigated  if  system 
users  know  the  exact  configuration  of  the  system  so  that 
system  differences  can  be  identified  in  the  training  scenario. 
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Differences  may  be  such  that  the  system  is  degraded  over  that 
being  used  in  the  fleet.  In  some  cases  systems  may  be 
upgraded  prior  to  fleet  release  of  the  upgrade  or 
modification.  Whichever  the  case,  it  is  imperative  that  the 
exact  system  configuration  be  known  to  the  users  of  the 
system . 

D .  SCOPE 

The  main  thrust  of  this  thesis  will  be  to  determine  the 
essential  elements  of  a  CM  policy  for  NAWCTSD  and  to  provide 
recommendations  for  implementing  a  CM  policy  at  NAWCTSD.  The 
thesis  will  include  a  study  of  at  least  one  example  of 
effective  (successful)  CM  policy  implementation  at  at  least 
one  Government  organization  and  one  industry  firm. 

E .  LIMITATIONS 

This  thesis  will  not  include  a  recommended  method  of 
internal  NAWCTSD  review  for  the  recommended  CM  policy  at 
NAWCTSD.  The  thesis  will  not  include  details  of 
implementation  for  any  specific  program  or  acquisition  being 
supported  or  conducted  at  NAWCTSD  nor  will  it  consider 
implementation  with  respect  to  any  individual  branch  or  other 
organizational  unit  having  CM  responsibilities  unique  to  a 
specific  program.  Rather,  the  recommended  policy  will  include 
the  essential  elements  of  a  comprehensive  CM  policy 
implementation  with  a  view  to  the  overall  policy  of  NAWCTSD 
and  its  CM  requirements  with  respect  to  existing  Government 
regulations.  Recommendations  concerning  organizational 
elements  and  individual  responsibilities  for  overall  CM 
implementation  will  be  included. 

This  thesis  will  not  attempt  to  explain  the  technical 
details  of  CM  as  practiced.  Rather,  it  will  concentrate  on 
overall  CM  policy  elements  and  implementation.  Technical 
explanations  concerning  automated  or  manual  CM  systems  will  be 
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only  generally  discussed  ■  or  referenced.  Technical 
explanations  will  be  kept  to  an  absolute  minimum  in  order  to 
facilitate  easy  reading  by  an  audience  which  may  not  be 
familiar  with  the  technical  aspects  of  CM. 

F.  ASSUMPTIONS 

It  is  assumed  that  the  reader  is  generally  familiar  with 
the  concepts  of  CM  as  practiced  in  both  Government  and 
civilian  organizations.  It  is  assumed  that  the  reader  has 
ready  access  to  Government  instructions,  written  policy, 
supplemental  written  material,  and  other  references  listed  in 
the  list  of  references.  It  is  also  assumed  that  the  reader 
has  sufficient  technical  background  to  independently  analyze 
technical  material  presented  but  not  explained  in  the  body  of 
the  text  as  it  refers  to  CM  issues  such  as  that  covering  the 
acquisition  of  software  and  hardware. 

G.  LITERATURE  REVIEW  AND  METHODOLOGY 

There  is  a  large  body  of  current  literature  from  which  to 
conduct  research  concerning  CM  theory.  This  thesis  is  not  so 
concerned  with  CM  theory  as  it  is  with  the  successful 
implementation  of  CM  policy  at  NAWCTSD .  Therefore,  the 
literature  searched  will  be  to  synthesize  information  gleaned 
from  an  agglomeration  of  general  information  concerning  CM 
policy  and  specific  information  concerning  the  successful 
implementation  of  CM  policy  at  one  comparable  Government 
entity  and  at  one  comparable  industrial  organization.  The 
methodology  employed  involves  data  searches  at  the  NPS 
library,  research  of  Government  regulations  and  instructions 
including  NAWCTSD  and  NAVAIR  instructions  and  implementing 
guidelines  and  instructions  from  other  Government  agencies  and 
industrial  firms.  Additionally,  Government  representatives 
from  various  agencies  and  from  civilian  institutions  will  be 
interviewed  to  determine  how  CM  policy  was  initiated  at  their 
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respective  organizations  or  in  their  acquisition  programs  and 
the  success  of  the  CM  policy  implemented. 

H.  DEFINITIONS  AND  ACRONYMS 

Appendix  B  provides  a  Glossary  of  Acronyms  used  in  this 
thesis.  See  Appendix  C  for  definitions  of  terms.  These 
definitions  were  derived  from  NAWCTSDINST  4130. _M,  Appendix  A, 
NAVAIRINST  4130. 1C,  Appendix  A,  and  DoD  Instruction  5000.2. 

I.  ORGANIZATION  OF  STUDY 

The  seven  chapters  of  this  thesis  are  organized  in  such 
a  manner  that  they  present  a  logical  progression  from  problem 
statement  to  conclusions  and  recommendations.  The  inclusion 
of  Appendix  A,  a  dendritic  analysis,  is  key  to  the  development 
of  a  satisfactory  conclusion  and  recommendations  describing 
the  essential  elements  of  a  NAWCTSD  Configuration  Management 
Policy.  It  is  key  because  it  represents  the  whole  of  the 
problem  in  a  graphical  format  that  is  easy  to  understand.  The 
organization  of  the  thesis  complements  the  organization  of  the 
problem  as  presented  in  Appendix  A  and  facilitates  development 
of  matrices  which  cross  reference  answers  to  questions  and 
data . 
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II.  LITERATURE  REVIEW  AND  THEORETICAL  FRAMEWORK 
A .  STRUCTURAL  FRAMEWORK 

The  structural  framework  for  this  thesis  is  based  on  a 
study  of  successful  implementation  of  CM  policy  at  a 
Government  and  industry  organization  as  well  as  a 
comprehensive  search  of  current  DoD,  DoN,  and  other  Government 
instructions,  specifications,  and  standards.  Personnel  from 
other  Government  agencies  and  from  industry  firms  which  have 
successfully  implemented  CM  under  a  CM  policy  were  interviewed 
and  provided  a  rich  resource  of  information  concerning  the 
essential  elements  of  a  CM  policy  and  current  theoretical 
knowledge  of  CM.  During  the  period  this  thesis  was  being 
written,  the  Perry  Memo  [Ref.  1]  began  to  have  a  significant 
effect  on  the  implementation  of  CM  policy  within  the 
acquisition  community.  As  much  as  possible,  research 
conducted,  and  the  structural  framework  of  this  thesis, 
includes  up-to-date  policy  that  encompassed  changes  made  to 
accommodate  the  paradigm  shift  in  acquisition  policy  mandated 
by  the  Perry  Memo  [Ref.  1] . 

The  National  Aeronautics  and  Space  Administration  (NASA) 
was  selected  as  a  comparable  Government  organization  to  study 
for  its  CM  policy  on  the  Shuttle  program.  The  Shuttle  program 
represents  a  large  and  complex  system  under  effective  hardware 
and  software  configuration  management  and  control.  This 
thesis  will  study  information  derived  from  NASA' s  software  and 
hardware  CM  policy  (See  Appendix  D)  as  it  relates  to 
development  of  the  complex  shuttle  hardware  and  software 
development,  modification,  and  life  cycle  support. 

Loral  Corporation,  the  Shuttle  software  development 
contractor,  was  chosen  as  a  comparable  industry  organization 
for  study  of  its  CM  policy.  Loral,  Incorporated  was  a  good 
choice  for  an  industry  firm  because  part  of  the  Loral  success 
story  in  CM  is  a  result  of  the  CM  policy  in  place  at  the  NASA. 
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The  implementation  of  a  successful  CM  policy  at  Loral  (Loral's 
own  policy,  not  the  NASA  CM  policy)  for  software  work  done  on 
the  Shuttle  system  under  contract  to  NASA  serves  as  a  good 
industry  model  for  design  of  similar  CM  policy  implementations 
in  other  organizations,  including  Government  organizations. 

Loral  was  chosen  because  it  represents  a  highly 
successful  software  development  company  involved  in  a  highly 
successful,  very  complex,  software  development  effort 
supporting  the  shuttle.  The  shuttle  software  development 
process,  at  Loral  in  Houston  TX,  was  rated  at  a  Level  Five 
Software  Process  Capability  Maturity  [Ref.  3],  the  highest 
level  achievable,  after  a  process  assessment  conducted  with 
the  assistance  of  the  Software  Engineering  Institute  [Ref.  4, 
p .  81 ,  par.  1.4.1]  . 

This  thesis  is  being  written  with  an  emphasis  on  DoD  CM 
policy  and  issues;  therefore,  the  U.S.  Army's  ATACMS-BAT 
program  was  studied  and  will  be  referenced  as  an  additional 
comparable  Government  organization  with  a  proven,  successful, 
CM  policy. 

Research  done  on  CM  policy  will  address  both  acquisition 
and  life-cycle  issues  as  part  of  the  structural  framework. 
Theoretically,  effective  implementation  of  CM  for  the  life 
cycle  begins  early  in  the  acquisition  phases. 

Other  areas  of  research  in  the  structural  framework  that 
are  applicable  to  solving  the  problem  of  developing  and 
implementing  a  successful  CM  policy  at  NAWCTSD  are  contained 
in  numerous  management  and  organizational  treatises  and  in 
DoD,  Don  and  other  Government  instructions  and  specifications. 
These  were  studied  to  determine  what  is  required  statutorily 
and  what  is  simply  recommended  They  were  also  analyzed  to 
determine  the  hierarchical  nature  of  the  instructions  and 
specifications  governing  CM  policy,  the  recommended  managerial 
policy  from  a  "best  practices"  perspective,  and  the  technical 
requirements  of  a  CM  policy. 
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Another  part  of  the  structural  framework  is  in  the  area 
of  standardization  and  program  integration  across  a  wide 
variety  of  platforms  serving  multiple  customers.  Policy  was 
studied  to  determine  if  a  competency  aligned  organization, 
such  as  NAWCTSD,  can  successfully  integrate  efforts  and 
standardize  on  procedures  effectively  based  on  existing 
Government  policy.  Standardization  of  the  CM  process  itself 
is  studied  to  determine  the  extent  to  which  CM  policy  should 
strive  to  standardize  processes  and  policy. 

Attention  is  also  given  to  the  involvement  of  upper 
management  in  the  success  of  CM  policy  implementation. 

B.  KEY  FACTORS  AFFECTING  IMPLEMENTATION  OF  CM 

Following  are  the  key  factors  affecting  implementation  of 
an  effective  CM  policy  at  NAWCTSD: 

1.  Determination  of  the  essential  elements  of  CM  to  be 
performed  by  NAWCTSD  for  the  entire  life  cycle  of  each  type  of 
system  under  its  cognizance.  Those  systems  represent  the  full 
spectrum  of  training  devices  from  simple  electro-mechanical 
systems  to  complex  simulators  such  as  the  F/A-18  Flight 
Simulator.  In  some  cases  there  are  a  large  number  of  trainers 
comprising  a  system,  such  as  at  a  Navy  "A"  school .  In  other 
cases  there  may  be  only  one  or  two  or  up  to  ten  simulators  to 
support  a  system  such  as  the  F/A-18  Flight  Simulators. 

2 .  Determination  and  agreement  of  the  principal 
elements  of  CM  across  a  wide  spectrum  of  disciplines  and 
across  a  diverse  number  of  organizational  competencies  at 
NAWCTSD . 

3.  Integration  of  the  efforts  of  individuals  within  the 
organizational  competencies  at  NAWCTSD. 

4.  Written  interpretation  of  a  specific  set  of  rules, 
directives,  and  regulations  concerning  implementation  of  CM 
within  the  Government  that  pertain  to  NAWCTSD . 


13 


C.  CAUSAL  RELATIONSHIPS 


There  are  a  number  of  causal  relationships  that  exist 
among  the  key  factors  that  impact  on  the  effectiveness  of  CM 
policy  implementation  at  NAWCTSD .  One  significant 
relationship  is  the  impact  that  the  organizational  structure 
of  NAWCTSD  imposes  on  the  requirement  that  CM  be  implemented 
in  a  "standardized"  fashion.  Customers  of  NAWCTSD  comprise 
elements  of  the  surface,  sub- surface,  aviation,  and 
intelligence  communities  within  the  Navy.  NAWCTSD  also 
acquires  training  systems  and  provides  DCS  for  those  training 
systems  for  the  Marine  Corps,  the  Air  Force,  the  Coast  Guard, 
and  other  Federal  agencies.  Support  for  Cog  2"0"  systems  is 
shared  over  several  competencies  within  NAWCTSD  such  as 
Project  Direction/Management,  Contracting,  Engineering,  and 
Logistics.  The  efforts  of  these  and  other  individual 
competencies  must  be  integrated  over  the  life  of  the  systems 
in  order  to  assure  effective  and  efficient  CM.  Therefore, 
there  is  a  causal  relationship  concerning  internal 
organizational  responsibility  and  overall  control  of  the  CM 
processes  and  systems.  Which  internal  organizations  will 
determine  CM  policy  and  which  internal  organizations  will 
implement  that  policy?  How  will  the  needs  of  multi- service 
customers  be  made  known  to  those  in  charge  of  policy 
development?  Each  of  these  questions  has  a  cause  and  effect 
centered  around  the  overall  organizational  structure.  These 
relationships  are  complicated  by  the  diverse,  multi-service, 
multi-agency  customer  base. 

There  are  causal  relationships  relating  to  Government 
instructions  and  directives  on  CM  and  the  individual 
interpretations  of  the  requirements  for  CM  based  on  those 
instructions  and  directives.  This  problem  is  especially 
profound  given  the  multi-service  nature  of  the  CM  systems  that 
must  be  implemented.  CM  concepts  become  mixed  when  viewed 
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from  the  perspective  of  a  multi-service  environment. 

D.  CONTRIBUTIONS  OF  THIS  THESIS  TO  THE  GENERAL  BODY  OF 
KNOWLEDGE 

This  thesis  reviews  the  general  body  of  knowledge 
concerning  the  essential  elements  of  CM  policy  and 
implementation  of  CM  policy  for  organizations  acquiring  and 
supporting  complex,  one-of-a-kind  or  few-of -a-kind  systems. 
It  also  provides  a  road  map  for  implementing  CM  in  a  multi¬ 
service  environment  and  within  the  organizational  framework  of 
a  competency  aligned  organization. 

It  addresses  CM  implementation  and  effective 
standardization  issues  in  a  diverse  organizational  climate. 
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III.  BACKGROUND  OF  CM  ISSUES  AT  NAWCTSD 


A.  BRIEF  HISTORY  OF  CM  AND  CM  POLICY  AT  NAWCTSD 

NAWCTSD  is  designated  as  an  Office  of  Primary 
Responsibility  (OPR)  per  NAVAIRINST  4130 . 1C  .  This  designation 
carries  with  it  certain  responsibilities.  Those 

responsibilities  are  to: 

(1)  Provide  CM  of  assigned  configuration  items 
throughout  their  life-cycle. 

(2)  Prepare  and  maintain  CM  plans  for  assigned 
configuration  items,  obtaining  approval  of  those  plans, 
and  assuring  proper  implementation  of  NAVAIRINST  4130. 1C. 

(3)  Manage  and  provide  direction  for  the  staffing  of 
all  engineering  change  proposals,  related  weapon  system 
engineering  change  proposals.  Trainer  Engineering  Change 
Proposals  (TECPs) ,  and  requests  for  major  and  critical 
deviations  and  waivers  from  initiation  until  submittal  to 
the  Trainer  Engineering  Change  Control  Board  (TECCB) . 

(4)  Implement  TECCB  directed  actions. 

(5)  Maintain  the  status  of  implementing  actions  for 
approved  engineering  changes,  deviations,  and  waivers. 

(6)  Conduct  audits  and  establishing  baselines. 

(7)  Establish  and  maintain  an  adequate  configuration 
status  accounting  system. 

NAWCTSD  has  complied  with  the  requirements  listed  above 
by  issuing  instructions  which  implemented  those  requirements. 
NAWCTSDINST  4130. _M  is  the  latest  instruction  issued.  Prior 
to  the  issuance  of  the  NAWCTSDINST  4130. _M  there  were  a  series 
of  NTSCINST  4130.x  implementing  instructions.  Each  of  those 
were  issued  in  compliance  with  updated  instructions  from 
NAVAIR.  To  date,  that  sequence  of  instructions  has  been 
sufficient  to  provide  a  measure  of  success  in  accomplishing 
configuration  management  and  control  over  the  inventory  of 
Cognizance  Symbol  2"0"  equipment. 

NAWCTSD,  under  several  different  names  since  it  became 
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the  Navy's  premier  training  devices  center  in  the  mid  1940s, 
has  supported  its  inventory  of  devices  in  an  excellent  manner. 
The  necessity  for  formulating  a  more  coherent  CM  policy  is  not 
because  NAWCTSD  has  failed  to  accomplish  its  assigned 
responsibilities  with  regard  to  CM,  but  because  it  is 
necessary  to  upgrade  its  capabilities  to  conform  to  more 
stringent  demands  from  customers  both  internal  and  external  to 
NAWCTSD  and  from  rapid  changes  in  technology. 

NAWCTSD  is  faced  today  with  the  same  problems  of  most 
industries.  That  is  the  problem  of  attempting  to  keep  abreast 
of  what  could  only  be  termed  revolutionary  changes  in 
technology.  Up  until  the  early  1980s  the  major  cost  of 
training  systems  was  in  the  hardware.  In  fact,  hardware 
comprised  the  bulk  of  the  system.  Software  was  a  lesser  cost 
item  though,  even  at  the  outset,  managing  software  presented 
new  and  unique  challenges  especially  with  respect  to 
configuration  management  and  configuration  status  accounting. 
Today,  the  major  cost  of  systems  is  in  the  development  and 
maintenance  of  the  software  which  comprises  the  bulk  of  the 
system's  capabilities. 

This  situation  presents  system  developers  with  the 
problem  of  performing  configuration  management  on  both 
hardware  and  software  and  of  integrating  that  effort.  This 
has  required  immense  change  and  flexibility  in  CM  technology, 
methods,  and  processes.  All  systems  developers  are  faced  with 
these  changes  and  are  attempting  to  respond. 

NAWCTSD  is  currently  in  the  process  of  updating  and 
implementing  CM  instructions  and  policy  because  of  the  many 
changes  that  have  and  continue  to  take  place  in  technology, 
methodology,  and  requirement  for  CM.  Added  to  those  changes, 
during  the  recent  past  there  has  been  a  revolutionary  change 
in  DoD  acquisition  policy.  The  recent  memorandum  on 
acquisition  reform  by  the  Secretary  of  Defense  will  likely 
result  in  additional  changes  in  CM  policy  at  NAWCTSD. 
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B.  UNIQUENESS  OF  THE  NAWCTSD  CM  EFFORT 

The  uniqueness  of  the  NAWCTSD  CM  effort  cannot  be 
overemphasized.  As  mentioned  previously,  NAWCTSD  serves  many 
customers.  Although  NAWCTSD  is  an  integral  part  of  the  NAVAIR 
team  and  is  functionally  under  the  direction  of  NAVAIR,  it  is 
also  an  integral  part  of  the  surface  and  sub- surface  Navy. 
For  many  years  NAWCTSD,  under  different  names,  was 
functionally  under  the  direction  of  several  different  Navy 
Systems  Commands  but  still  always  provided  services  to  the 
many  different  Navy  commands  on  both  coasts.  They  also 
provided  and  continue  to  provide  services  to  the  Marine  Corps 
and  other  military  Services  and  did  so  long  before  "jointness" 
was  a  buzzword.  At  this  time,  NAWCTSD  is  working  closely  with 
NASA  under  a  Memorandum  of  Agreement  (MOA)  and  has  ties  with 
other  non-DoD  agencies .  This  has  made  the  problem  of 
implementing  CM  in  a  standardized  fashion  immensely  difficult. 

Within  the  Navy  alone,  the  surface  differs  from  the  sub¬ 
surface  Navy,  both  of  which  differ  from  the  aviation  part  of 
the  Navy  on  a  number  of  issues  concerning  documentation, 
training,  systems  procurement,  and  life-cycle  support.  There 
are  differences  between  Services  and  between  non-DoD  agencies 
in  their  requirements  for  documentation,  training,  systems 
procurement,  and  life-cycle  support  issues. 

Additionally,  NAWCTSD  may  be  tasked  to  provide  life-cycle 
support,  including  CM,  on  a  device  procured  by  another  agency 
and  then  inducted  into  the  NAWCTSD  inventory  as  a  Cognizance 
2"0"  device  or  system. 

In  the  aggregate,  NAWCTSD  is  faced  with  a  unique 
challenge  in  performing  CM  both  during  acquisition  and  after 
acceptance  by  the  user  agency  simply  because  of  the  many 
differences  in  the  wide  variety  of  customers  serviced  by 
NAWCTSD.  This  challenge  cannot  be  overlooked  in  the 
development  and  implementation  of  any  over-arching  policy. 
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such  as  a  CM  policy. 

Added  to  the  difficulties  of  multiple  and  diverse 
customers,  is  the  diversity  in  the  products  delivered  by 
NAWCTSD.  The  product  may  consist  of  an  immensely  complex, 
one-of-a-kind  or  f ew-of -a-kind  device.  Or  it  may  consist  of 
a  less  complex  device  procured  in  larger  numbers  but  widely 
distributed.  It  is  the  diversity  of  the  types  of  devices  and 
their  distribution  that  adds  greatly  to  the  complexity  of 
establishing  effective  CM  over  a  given  device. 

As  an  example  of  a  complex,  f ew-of -a-kind  device,  the 
F/A-18  trainer  suite  consists  of  number  of  weapon  tactics 
trainers  which  are  immensely  complex  and  include  a  state-of- 
the-art  visual  system.  The  suite  also  includes  a  number  of 
operational  flight  trainers,  somewhat  less  complex  than  the 
weapon  tactics  trainers,  but  does  still  have  a  visual  system. 
The  last  part  of  the  suite  consists  of  several  part  task 
trainers,  which  are  the  least  complex  but  by  no  means  simple 
systems . 

All  of  the  systems  in  the  trainer  suite  rely  heavily  on 
digital  technology  and  are  driven  by  huge  sophisticated 
software  routines.  The  systems  are  widely  distributed 
throughout  the  United  States  and  overseas  in  several 
locations.  They  were  procured  over  a  period  of  approximately 
ten  years  and  thus  represent  a  large  disparity  in  technology 
from  the  first  to  the  last  system  procured.  Several  of  the 
weapon  tactics  trainers  were  procured  by  NAVAIR  with  an  assist 
task  from  NAWCTSD  but  all  are  Cognizance  Symbol  2"0"  systems 
for  support  purposes . 

The  F/A-18  aircraft  has  undergone  evolutionary 
modifications  since  it  was  introduced  into  the  fleet,  and  it 
continues  to  undergo  upgrades  and  modifications  to  both 
software  and  hardware.  All  of  these  modifications  have  to  be 
incorporated  into  the  F/A-18  trainer  suite,  if  applicable,  and 
must  be  tracked  for  CM  purposes  both  by  the  organizations 
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responsible  for  the  aircraft  baselines  and  by  the 
organizations  responsible  for  the  trainer  suite  baselines . 

As  can  be  seen  from  a  description  of  the  F/A-18  trainer 
suite,  the  problem  of  performing  CM  on  that  system  is 
immensely  challenging  from  a  number  of  perspectives.  It  is  a 
challenge  because  of  the  number  of  different  versions  of  the 
system  in  existence.  It  is  a  challenge  because  NAVAIR 
procured  some  of  the  systems  and  NAWCTSD  procured  some.  The 
systems  are  widely  distributed  geographically  and  this  adds  to 
the  problem  of  effective  configuration  management  and  control 
since  each  system's  baseline  must-be  completely  and  accurately 
documented.  The  requirements  for  changes  to  the  systems  must 
be  tracked  from  aircraft  changes  as  well  as  possible  changes 
to  the  simulation  systems  due  to  evolutionary  development  or 
latent  problems  in  either  software  or  hardware.  Even  changes 
in  training  doctrine  or  tactics  from  the  operational  side  of 
the  house  must  be  documented  and  tracked. 
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IV.  METHODOLOGY 


A.  RESEARCH  DESIGN 

Research  for  this  thesis  will  be  conducted  using  Appendix 
A  as  a  road  map.  The  dendritic  approach  outlined  in  Appendix 
A  provides  a  breakdown  of  the  critical  issue  into  sub¬ 
objectives  which  are  further  broken  down  into  sub- sub¬ 
objectives  as  needed. 

The  initial  stages  of  the  research  involved  a 
comprehensive  analysis  of  the  literature  identified  in  the 
literature  search  as  applicable.  Proceeding  from  that 
analysis  several  of  the  subsidiary  research  questions  were 
answered.  As  an  example,  the  principal  elements  of  CM  policy 
and  requirements  established  by  the  DoN,  DoD,  and  other 
Federal  Government  regulations  were  clearly  identified  and 
catalogued  according  to  their  order  of  precedence.  Which 
regulations,  instructions,  and  directives  apply  to  the  NAWCTSD 
CM  effort  and  which  are  subordinate  or  superior  were 
identified . 

A  review  of  the  NASA,  Loral,  and  ATACMS-BAT,  CM  policies 
was  performed  to  clarify  the  direction  taken  by  those 
organizations  to  determine  their  best  CM  policy.  This 
approach  to  solving  some  of  the  subsidiary  questions  is 
appropriate  simply  because  not  all  of  the  answers  to 
determining  the  essential  elements  of  CM  are  contained  in  DoD 
and  Don  regulations.  A  study  of  similar  organizations  helped 
clarify  which  policy  elements  were  critical,  and,  equally 
important,  which  ones  worked  best  to  successfully  implement 
CM. 

One  visit  was  made  to  NAWCTSD  to  discuss  implementation 
policy  with  Competency  3.0.  Competency  3.0  provided  a  draft 
of  the  proposed  changes  to  the  existing  CM  instruction, 
NAWCTSDINST  4130. _M  and  clarifying  remarks  concerning  the 
present  status  of  CM  implementation  at  NAWCTSD.  No  formal 
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questionnaires  were  developed  or  used  at  the  initial  meeting 
with  Competency  3.0  personnel  since  the  author  is  familiar 
with  the  problems  and  personnel  and  only  required  an  update  on 
the  status  of  the  new  instruction  being  developed. 

Other  NAWCTSD  personnel  were  interviewed  to  get  a  flavor 
for  the  organizational  problems  involved  in  implementing  an 
effective  policy.  Notes  resulting  from  those  interviews  was 
used  in  the  overall  analysis  of  the  data.  No  formal 
questionnaires  were  used. 

Personnel  responsible  for  CM  policy  and  implementation 
from  NASA,  Loral,  and  the  ATACMS-BAT  program  office  were 
interviewed  over  the  telephone.  Infomation  concerning  their 
policies  was  obtained.  Pertinent  information  is  contained  in 
Appendices  D,  E,  and  F  and  was  used  to  supplement  information 
contained  in  referenced  texts,  instructions,  and 
specifications . 

Several  personnel  who  practiced  CM  at  the  grassroots 
level  of  the  organizations  involved  in  this  study  were 
interviewed.  Thus,  the  author  gained  a  working  level 
perspective  of  the  effectiveness  of  implementing  CM  policy. 

The  information  derived  was  used  to  enhance  development 
of  policy  for  NAWCTSD. 

B .  ANALYTIC  STRUCTURE 

Analysis  of  the  data  derived  from  the  applicable 
literature  and  interviews  was  used  to  develop  a  data  matrix 
which  linked  data  sources  to  items  to  be  studied.  From  that 
matrix,  it  was  decided  which  subsidiary  research  questions 
could  be  completely  and  adequately  answered  from  the 
literature,  instructions,  specifications,  and  technical 
documents  available  and  which  required  a  more  heuristic 
approach  by  developing  answers  based  on  the  study  of  other 
successful  CM  policies  and  the  interviews  conducted.  Key  to 
the  successful  completion  of  this  thesis  is  contained  in 
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Appendix  A.  Appendix  A  provides  a  sufficient  breakdown  of  the 
critical  issue,  the  research  question,  to  assure  a 
comprehensive  answer  to  all  of  the  subsidiary  research 
questions.  Questions  asked  during  interviews  and  answers 
to  those  questions  were  analyzed  and  included  in  the  matrix 
described  in  the  preceding  paragraph.  Analysis  of  those 
questions  and  answers  is  expected  to  contribute  significantly 
to  the  body  of  knowledge  to  be  developed  as  a  result  of  this 
study  and  to  a  more  "practical"  solution  to  the  research 
question . 

The  results  of  the  analysis  are  the  identification  of  the 
essential  elements  of  a  CM  policy  and  recommendations 
necessary  to  implement  a  CM  policy  at  NAWCTSD.  Careful 
scrutiny  of  Appendix  A  assured  that  all  relevant  and  important 
issues  were  addressed  and  questions  answered. 
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V.  PRESENTATION  OF  DATA 


A.  INFORMATION  DERIVED  FROM  LITERATURE  SEARCH 

The  following  paragraphs  present  information  derived  from 
searching  Government  regulations,  instructions,  standards,  and 
other  pertinent  literature  concerning  CM.  The  facts  presented 
in  this  chapter  will  be  analyzed  in  Chapter  VI .  All 
information  is  referenced  to  allow  the  reader  easy  access  to 
source  documentation  for  further  study  if  desired. 

Only  the  information  concerning  CM  policy  or 
implementation  of  that  policy  is  presented.  Only  the  most 
important  facts  are  presented  in  the  interest  of  readability 
and  brevity.  Information  is  organized  by  several  of  the  most 
useful  sources.  Each  sub- section  below  provides  information 
from  the  source  listed  in  the  sub-section  title.  Within  sub¬ 
sections,  additional  references  are  provided  as  appropriate. 
A  wealth  of  information  was  derived  from  the  "Military  Project 
Management  Handbook,  "  other  sources  of  infoirmation  in  the 
remaining  sections  do  not  contain  information  that  was  a 
repeat  of  information  contained  in  Section  1  covering  the 
"Military  Project  Management  Handbook." 

1.  "Military  Project  Management  Handbook" 

Sources  of  regulations  concerning  CM  are  found  at  both 
the  Department  of  Defense  (DoD)  level  and  at  the  Service 
level.  Following  is  a  list  of  sources  [Ref.  5,  p.  8.2]: 

DoD  Instruction  5000.2,  Part  9,  Sections  A  and  B,  "CM  and 

Technical  Data  Management" 

DoD-STD-100,  "Engineering  Drawing  Practices" 

DOD-STD-2167A,  "Defense  Systems  Software  Development" 

DoD-STD-2168,  "Software  Quality  Assurance" 
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MIL-STD-480B,  "Configuration  Control  -  Engineering 
Changes,  Deviations,  and  Waivers" 

MIL-STD-973,  "Configuration  Management" 

MIL-HDBK-61,  "Configuration  Management"  (aids  in  the 
implementation  of  Draft  MIL-STD-973) 

IEEE  Standard,  828-1983,  "IEEE  Standards  for  Software  CM 
Plans " 

NASA  Technical  Memorandum  85908,  "Software  Control  and 
System  Configuration  Management;  A  Systems-Wide 
Approach" 

The  above  sources  are  not  inclusive  of  all  sources  referenced 
in  this  thesis;  they  are  the  sources  listed  in  the  Military 
Project  Management  Handbook. 

Configuration  management  is  different  from  configuration 
control.  (See  Appendix  C  for  definitions  of  each.) 
Configuration  management  is  a  set  of  processes  which  have 
specific  product  relationships.  Configuration  control  is  a 
generalized  process.  [Ref.  5,  p.  8.3] 

DOD-STD-2167A  is  concerned  with  software  development  and 
therefore  does  not  consider  configuration  management  in  a 
system-wide  context  as  do  many  of  the  other  sources  used  in 
the  research  phase  of  this  thesis.  However,  many  of  the  same 
principles  apply  to  both  hardware  and  software  CM.  This 
thesis  will  consider  the  facts  derived  from  DoD-STD-2167A 
whenever  those  facts  may  be  considered  appropriate  to  the 
development  of  overall  or  system-wide  CM  policy. 

Configuration  Management  for  both  hardware  and  software 
begins  at  the  time  of  contract  award.  The  Government's 
configuration  management  plan  should  be  developed  early  in  the 
concept  exploration  and  definition  life-cycle  phase,  and 
should  be  updated  at  the  beginning  of  each  succeeding  phase  to 
reflect  changing  requirements.  [Ref.  5,  p.  8.4-5]  The 
Government  CM  plan  and  the  contractor's  CM  plan  should,  as  a 
minimum,  be  coordinated.  [Ref.  5,  p.  8.5]  The  contractor  CM 
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plan  should  have  separate  sections  detailing  the  contractor's 
process  and  procedures  for  configuration  identification, 
conf  igurat ion  control ,  status  accounting,  subcontractor/vendor 
control,  configuration  audits,  and  life-cycle  phasing 
considerations.  [Ref.  5,  p.  8.6] 

In  managing  the  process  and  activities  of  CM,  it  is 
necessary  that  the  requirements  and  provisions  of  the 
contractually  imposed  standards  be  incorporated  into 
subcontractor  statements  of  work  (SOWs) ,  including  all 
elements  of  a  comprehensive  configuration  management  program. 
[Ref.  5,  p.  8.4] 

The  configuration  change  control  process  used  by  the 
contractor  must  [Ref.  5,  p.  8.4]  ; 

1.  Ensure  effective  control  of  all  configuration 
items  and  their  approved  configuration  identifications. 

2 .  Propose  engineering  changes  to  configuration 
items,  request  deviations  or  waivers  for  pertinent  items, 
prepare  software  change  notices  (SCNs) ,  and  prepare 
notices  of  revision  (NORs)  on  the  appropriate  form.  The 
NOR  is  used  only  for  proposing  changes  to  documentation 
which  required  revision  after  engineering  change  proposal 
(ECP)  approval. 

3 .  Establish  a  developmental  configuration  for  each 
software  configuration  item. 

4.  Maintain  current  copies  of  deliverable 
documentation  and  code. 

5  .  Provide  the  contracting  agency  access  to  documents 
and  code  under  configuration  control. 

6 .  Control  the  preparation  and  dissemination  of 
changes  to  items  under  configuration  control  so  that  they 
reflect  only  approved  changes . 

Changes  to  configuration  items  which  have  been  placed 
under  configuration  control,  by  the  contractor,  are 
accomplished  by  submitting  requests  for  waiver,  deviations, 
NORs,  and  SCNs  [Ref.  5,  p.  8.5]. 
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Interface  management,  especially  on  large  systems,  may  be 
handled  by  a  separate  interface  or  integration  contractor. 
The  prime  development  contractor's  CM  plan  is  required  to 
describe  either  the  contractor's  interface  identification  and 
control,  or  the  separately  administered  interface  management 
program.  [Ref.  5,  p.  8.5]  Contractor  CM  plans  are  delivered 
as  a  contract  deliverable  (CDRL)  item  subject  to  Government 
approval.  [Ref.  5,  p.  8.7] 

One  of  the  specific  standard  requirements  for  a  CM  plan 
is  to  address,  as  a  minimum,  the  configuration  control, 
interchangeability,  and  interoperability  for  all  Non- 
developmental  Items  (NDIs) .  [Ref.  5,  p.  8.7] 

DoD  Instruction  5000.2  sets  policy  to  be  followed  by  the 
program  manager,-  whereas  the  various  standards  establish  the 
requirements  for  implementing  that  policy.  Standards,  not  DoD 
directives  and  instructions,  are  imposed  on  contractors  as 
contractually  binding  requirements  documents  to  the  extent 
specified  in  the  acquisition  documents.  It  is  important  that 
DoD  directives  and  instructions  not  conflict  with  DoD 
standards  since  standards  are  imposed  on  contractors.  [Ref. 
5,  p.  8.8-9] 

Most  systems  are  composed  of  one  or  more  configuration 
items.  A  configuration  item  may  be  hardware  or  software,  and 
it  may  be  decomposed  into  lower-level  sub-elements. 
Configuration  items  are  classified  as  prime  item,  software 
item,  critical  item,  or  non-complex  item  [Ref.  5,  p.  8.14] . 
Prime  items  are  documented  with  type  B1  and  Cl  specifications. 
Software  items  are  documented  with  type  B5a,  C5 ,  or  B5b 
specifications.  Critical  items  are  documented  with  type  B2 
and  type  C2  specifications.  Non-complex  items  are  documented 
with  type  B3  and  C3  specifications  [Ref.  5,  p.  8.14-8.15]. 
(See  the  section  labeled  MIL-HDBK-61  for  additional 
information  concerning  configuration  identification.) 

Firmware  can  be  treated  in  configuration  management  as: 
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1.  Non-developmental  hardware  and  software. 

2.  Non-developmental  hardware  and  Government- 

developed  software. 

3.  Government -developed  hardware  and  non- 

developmental  software. 

4.  Government -developed  hardware  and  software. 

Each  of  these  different  mixes  must  be  understood  and  both 
identified  and  controlled  in  light  of  their  unique  nature. 
This  may  mean  references  to  the  firmware  identifications  in 
either  software  specifications ,  and  drawings  or  hardware 
specifications  and  drawings  or  both.  [Ref.  5,  p.  8.15  - 

8 . 16] 

The  Government  must  be  careful  to  invoke  the  level  of 
configuration  management  necessary  for  the  contract  in  the 
statement  of  work  (SOW)  .  The  SOW  must  identify  the  importance 
of  the  configuration  management  activity,  and  must  describe 
the  configuration  management  requirements  in  a  separate  and 
clearly  identified  section  on  the  same  level  as  other  major 
development  and  management  activities.  [Ref.  5,  p.  8.16] 

The  SOW  should  state  how  the  Government  will  interact 
with  the  contractor  on  the  configuration  management  program. 
This  will  include  whether  or  not  the  Government  will  chair 
technical  review  meetings,  attend  change  control  board  (CCB) 
or  software  change  control  board  (SCCB)  meetings,  attend 
interface  control  working  group  (ICWG)  meetings,  and  conduct 
periodic  audits  of  the  configuration  management  system  and 
specifications  during  the  project.  [Ref.  5,  p.  8.16] 

2.  DoD  Directive  4245. 7 -M 

This  directive,  titled  "Transition  from  Development  to 
Production, "  discusses  the  importance  of  configuration  control 
in  reducing  risk  in  a  program.  It  denounces  the  direct 
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application  of  boilerplate  policies  and  invoking  military 
specifications  which  lead  to  ineffective  control  or  overly 
complex  and  costly  approaches  to  managing  configuration.  Many 
problems  can  be  avoided  by  implementing  a  good  configuration 
control  system.  A  poor  configuration  control  system  leads  to 
many  pitfalls  such  as  an  unknown  design  baseline,  excessive 
production  rework,  poor  spares  effort,  stock  purging  rather 
than  stock  control,  and  an  inability  to  resolve  field 
problems.  Poor  configuration  control  is  a  leading  cause  of 
increasing  program  costs  and  lengthening  procurement 
schedules.  [Ref.  6,  p.  3-30]  A  comprehensive  CM  policy  will 
address  the  implementation  of  a  configuration  control  system. 


3.  NAVAIRINST  4130. 1C 

This  instruction,  titled  "Naval  Air  Systems  Command  CM 
Policy,"  implements  SECNAVINST  4130.2  (referenced  in 
NAVAIRINST  4130. 1C) .  SECNAVINST  4130.2  will  not  be  covered  in 
this  chapter  since  the  interpretation  of  that  instruction  is 
embodied  in  the  NAVAIRINST  4130. 1C.  NAVAIRINST  4130. 1C 
establishes  policy  and  assigns  responsibility  for  CM.  It  also 
provides  guidance  for  processing  change  proposals.  It 
discusses  CCBs  and  their  structure  and  authority.  The 
information  presented  in  this  subsection  will  concentrate  on 
general  CM  policy  rather  than  on  detailed  process  guidance. 
NAVAIRINST  4130. 1C  is  relevant  to  determining  CM  policy  for 
NAWCTSD  since  NAVAIR  is  in  the  administrative  chain  of  command 
for  NAWCTSD. 

NAVAIR  has  designated  NAWCTSD  as  an  Office  of  Primary 
Responsibility  (OPR) .  An  OPR  is  assigned  primary 
responsibility  for  system  acquisitions.  A  designated  OPR  has 
certain  authority  and  certain  limitations  regarding  CM  as 
provided  in  NAVAIRINST  4130. 1C.  Authority  and  limitations 
relevant  to  CM  policy  will  be  discussed  in  this  subsection. 
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Most  of  the  information  presented  in  this  subsection  is  quoted 
directly  from  NAVAIRINST  4130. 1C.  Although  this  information 
could  simply  be  referenced,  it  is  felt  that  readability  of  the 
overall  thesis  is  improved  by  including  the  information  in  the 
body  of  the  thesis.  This  both  emphasizes  information  and 
limits  it  to  that  which  the  author  felt  was  most  important  in 
determining  CM  policy.  NAVAIRINST  4130. 1C,  because  of  its 
importance  in  determining  CM  policy  for  NAWCTSD  is  critical  in 
defining  what  that  policy  should  encompass. 

It  is  the  policy  that  Class  I  engineering  changes  and 
major  or  critical  deviations  will  be  implemented  only  upon 
approval  of  a  CCB.  Rapid  Action  Minor  Engineering  Changes 
(RAMECs)  will  not  be  implemented  prior  to  CCB  approval. 
Configuration  control  requirements  are  to  be  included  in 
acquisition  documents  per  NAVAIRINST  4275. 3F,  "Implementation 
of  Configuration  Control,"  MIL-STD-480B,  and  MIL-STD-481. 
[Ref.  7,  par.  4,  p.  1] 

OPRs  are  responsible  for  [Ref.  7,  par.  6. a,  p.  2] ; 

1.  providing  CM  of  assigned  Cis  throughout  their  life 
cycle; 

2 .  preparing  and  maintaining  CM  plans  for  assigned 
CIS;  obtaining  approval  of  these  plans,  and  assuring 
proper  implementation  of  NAVAIRINST  4130. 1C; 

3.  managing  and  providing  direction  for  the  staffing 
of  all  engineering  change  proposals,  RAMECs,  and  requests 
for  major  and  critical  deviations  and  waivers  from 
initiation  until  submittal  to  a  CCB; 

4.  implementing  CCB  directed  actions; 

5.  maintaining  the  status  of  implementing  actions  for 
approved  engineering  changes,  deviations,  and  waivers; 

6.  conducting  audits,  establishing  baselines;  and 

7.  establishing  and  maintaining  an  adequate 
configuration  status  accounting  system. 
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The  Configuration  Management,  Program  Policy  and 
Resources  Division  (AIR-100)  has  the  authority  to  enforce 
NAVAIRINST  4130. 1C.  It  also  governs  the  CCB  for  the 
Commander,  Naval  Air  Systems  Command.  AIR- 100  governs  the 
operation  of  ALL  (author's  highlight)  existing  CCBs  and  has 
the  authority  to  charter  subordinate  CCBs.  AIR-100  also  has 
the  authority  to  review  and  approve  OPR  CM  plans.  [Ref.  7, 
par  6.b,  p.  2,3] 

Following  are  policy  elements  concerning  CM  during  the 
acquisition  phase  [Ref.  7,  par.  1.4,  p.  l-l  -  1-2]: 

1.  Concept  Exploration  and  Definition  (CE&D)  Phase. 
Initial  CM  plans  are  formulated  and  the  functional 
baseline  is  established. 

2.  Demonstration  and  Validation  (DEMVAL)  Phase.  CM 
plans  are  revised,  functional  baseline  is  updated, 
allocated  baseline  is  established. 

3.  Engineering  and  Manufacturing  Development  (EMD) 
Phase.  CM  plans  are  revised  and  functional  and  allocated 
baselines  are  updated. 

4.  Production  and  Deployment/Operations  and  Support 
Phases.  CM  plans  are  revised,  functional  and  allocated 
baselines  are  updated  by  a  functional  configuration 
audit,  product  baseline  is  established  by  a  physical 
configuration  audit,  and  the  configuration  status 
accounting  record  is  coordinated  with  operating  and 
support  activities. 

When  more  than  one  Government  activity  is  involved  in  the 
development,  acquisition,  modification,  or  support  of  a 
configuration  item,  a  mutually  approved  CM  plan  will  be 
included  as  part  of  the  program  interface  agreement  [Ref.  7, 
par.  1.5,  p.  1-2]  . 

The  OPR  will  ensure  that  each  contract  for  a  Cl  contains 
appropriate  provisions  for  CM  plans.  Cl,  CC,  configuration 
audits,  and  CSA  documents  as  outlined  by  NAVAIRINST  4130. 1C 
[Ref.  7,  par.  1.6,  p.  1-2]. 

If  an  OPR  has  more  than  one  Cl  under  its  management,  the 
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use  of  an  umbrella  CM  plan  is  recommended.  An  umbrella  CM 
plan  addresses  the  overall  CM  organization  and  planning  which 
will  be  used.  A  separate  addendum  may  then  be  prepared  for 
each  assigned  Cl  explaining  and  further  tailoring  specific 
policies  and  procedures  to  be  followed  to  accomplish  CM  of  the 
item.  [Ref.  7,  par.  2.2.2,  p.  2-2]  The  author  could  not  find 
reference  to  other  organizations  outside  of  the  DoD. 

Separate  CM  plans  will  be  required  from  each  contractor 
who  is  developing  and  supplying  hardware  and/or  software  to 
the  Navy.  The  OPR  will  assure  that  contractor  CM  plans  are 
consistent  with  its  own  CM  plans,  NAVAIRINST  4130. 1C,  and  with 
the  total  program  needs.  [Ref.  7,  par.  2.3.1,  p.  2-2] 

The  OPR  will  schedule  and  conduct  functional  and  physical 
configuration  audits  following  MIL-STD-1521B .  Normally,  due 
to  the  nature  and  criticality  of  configuration  audits,  they 
will  be  performed  by  Government  personnel.  [Ref.  7,  par. 4. 3, 
p.  4-1]  The  reader  is  invited  to  review  Figure  4-1,  page  4-2, 
in  NAVAIRINST  4130. 1C,  for  a  complete  (detailed)  list  of 
reviews  and  configuration  audits  to  be  performed  over  the  life 
cycle  of  a  system.  It  is  not  suggested  that  Figure  4-2 
contains  information  that  should  be  included  in  a  CM  policy, 
however,  the  information  is  relevant  to  details  for 
implementing  CM  policy  and  should  become  familiar  to  personnel 
required  to  implement  CM  under  the  authority  of  NAVAIRINST 
4130. 1C. 

The  OPR  will  ensure  that  provisions  for  configuration 
audits  are  included  in  each  procurement  contract,  usually  in 
the  SOW  [Ref.  7,  par.  4.4,  p.  4-1] . 

The  authority  to  approve  or  disapprove  Class  I 
engineering  change  proposals,  RAMECs,  and  major/critical 
deviations  or  waivers  for  PEO  and  NAVAIR  managed  items  resides 
with  the  NAVAIR  CCB,  chaired  by  AIR-100.  This  authority  may 
be  delegated  to  an  OPR  for  Class  I  engineering  change 
proposals  during  the  CE&D,  DEMVAL,  and  EMD  phases  [Ref.  7, 
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par.  5.3.2,  p.  5-1]. 

NAWCTSD  is  a  full  time  associate  member  of  the  NAVAIR  CCB 
[Ref.  7,  par.  5.13.b,  p.  5-9].  The  remainder  of  NAVAIRINST 
4130. 1C  is  concerned  with  details  of  change  processes  and 
other  detailed  implementing  information.  NAVAIRINST  4130. 1C 
is  a  comprehensive  document  covering  all  aspects  of  CM  for  the 
NAVAIR  community.  The  summary  information  presented  in  this 
subsection  was  gleaned  to  identify  the  salient  points  relevant 
to  CM  policy  and  implementation.  The  instruction  is  much 
broader  in  scope,  however. 

4.  DoD  Instruction  5000.2,  Part  9,  Section  A 

Because  of  the  importance  of  DoDI  5000.2,  the  following 
paragraphs  are  quoted  verbatim  from  the  instruction.  DoD 
Instruction  5000.2,  under  policies,  states  that  an  effective 
configuration  management  program  shall  be  established  to 
implement  the  decisions  made  in  the  systems  engineering 
process  by  [Ref.  8,  Part  9A,  par.  2(a),  subpar. 

(1)  ,  (2)  ,  (3)  ,  (4)  ,  p.  9-A-l]  : 

(1)  Identifying,  documenting,  and  verifying  the 
functional  and  physical  characteristics  of  a 
configuration  item, 

(2)  Controlling  changes  to  an  item  and  its 
documentation, 

(3)  Recording  the  configuration  of  actual  items,  and 

(4)  Auditing  the  configuration  item  and  its 
configuration  identification. 

DoDI  5000.2,  also  under  policies,  states  that 
configuration  management  shall  be  applied  to  any  item  [Ref. 
8,  Part  9A,  par.  2(b),  subpar.  (1) , (2) ,  p.  9-A-l, 2]: 

(1)  Developed  wholly  or  partially  with  Government  funds, 
including  any  Non-developmental  Items  (NDIs)  when  the 
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development  of  technical  data  is  required  to  support  off- 
the-shelf  equipment  or  software,  or 

(2)  Designated  for  configuration  management  for  reason 
of  integration,  logistics  support,  or  interface  control. 


DoD  Instruction  5000.2,  under  procedures,  describes  the 
requirements  of  a  configuration  management  program  as  [Ref. 
8,  Part  9A,  par.  3(a),  subpar .  (1) , (2) , (3) ,  p.  9-A-2] : 

1.  Procedures  that  must  be  tailored  consistent  with 
the  complexity,  criticality,  quantity,  size,  and  the 
intended  use  of  the  CIs.  It  requires  the  development  of 
standard  processes,  and  requires  that  these  processes  be 
used,  but  requires  that  they  be  tailored  by  means  of  the 
application  of  relevant  military  standards  which  are 
adapted  to  specific  program  characteristics. 

2.  Configuration  management  activities  conducted  by 
the  Government  program  managers  during  the  acquisition 
program.  It  requires  that  these  activities,  initially 
conducted  by  the  program  manager,  transfer  to  the  various 
Service  systems,  logistics,  or  material  commands  when  the 
Cl  is  transferred  from  the  control  of  the  program 
manager . 

3  .  The  processes  and  procedures  established  by  mutual 
agreement,  and  documented  by  the  lead  DoD  Component  when 
more  than  one  DoD  Component  is  involved  in  the 
acquisition,  modification,  or  support  of  the  Cl. 

Configuration  items  will  be  directly  traceable  to  the 
work  breakdown  structure  [Ref.  8,  Part  9A,  par.  3.b,  subpar 
(1) ,  p.  9-A-2]  The  WBS  handbook  is  being  upgraded  to  include 
more  details  on  the  implementation  of  a  WBS  for  software  since 
this  is  not  clearly  defined  in  DoDI  5000.2  [Ref.  5,  p.  8.9]  . 

Configuration  baselines  will  be  used  to  ensure  an  orderly 
transition  from  one  major  commitment  point  to  the  next.  These 
points  are  normally  milestone  decisions  [Ref.  8,  Part  9A, 
par.  3 .c,  p.  9-A-2] . 

Configuration  changes  will  be  controlled  in  accordance 
with  MIL-STD-973.  A  configuration  control  board  will  be 
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established  to  review  proposed  changes  to  approved 
configuration  identification  [sic]  and  advise  the  Program 
Manager.  [Ref.  8,  Part  9A,  par.  3.e,  p.  9 -A- 3] 

5.  MIL-STD-973 

MIL-STD-973,  titled  " Conf iguration  Management , "  contains 
information  that  is  generally  at  a  level  below  that  considered 
in  this  thesis  for  CM  policy.  Also,  many  of  the  sections  in 
MIL-STD-973  are  covered  in  other  sections  of  this  chapter  and 
are  appropriately  referenced.  The  Military  Project  Management 
Handbook  referenced  MIL-STD-973  frequently  but  once  again,  the 
references  were  at  the  implementation  level  vice  the 
programmatic  or  policy  level.  Therefore,  although  MIL-STD-973 
will  be  immensely  important  in  the  future  for  implementing  CM 
on  specific  systems  only  one  element  is  considered  here  for  at 
the  policy  level  as  indicated  in  the  following  paragraph. 

Configuration  management  efforts  are  not  considered 
peripheral  to  the  overall  systems  development  effort. 
Contractor  CM  personnel  must  participate  in  (not  just  attend) 
all  technical  reviews  conducted  [Ref.  9,  para.  4.2.4]. 

6.  DOD-STD-2167A 

DoD-STD-2167A,  titled  "Defense  Systems  Software, "  states 
that  the  contractor  shall  perform  configuration  management  in 
compliance  with  the  following  requirements  [Ref.  10,  Section 
4.5.2,  p.  17] : 

1.  Establish  a  development  configuration  for  each 

computer  software  configuration  item  CSCI . 

2.  Maintain  current  copies  of  the  deliverable 

documentation  and  code. 

3.  Provide  the  contracting  agency  access  to 

documentation  and  code  under  configuration  control. 
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4 .  Control  the  preparation  and  dissemination  of 
changes  to  the  master  copies  of  deliverable  software  and 
documentation  that  have  been  placed  under  configuration 
control  so  that  they  reflect  only  approved  changes. 

7.  MIL-HDBK-61 

MIL-HDBK-ei,  titled  "Configuration  Management ,  "  describes 
the  life  cycle  related  activities  of  CM  from  Concept 
Exploration  and  Development  to  disposition  of  a  system.  It 
states  that  there  is  a  need  to  have  CM  purview  of  product 
development  description  documents  as  well  as  interface  control 
drawings  and  documents .  Interface  documents  may  describe 
interfaces  between  hardware  components  and  software  components 
or  between  similar  components.  They  may  also  describe 
interfaces  between  hardware  and  software.  The  important  thing 
is  that  CM  is  presented  in  terms  of  a  system  and  is 
accomplished  for  the  life-cycle  of  the  system.  [Ref.  11, 
section  3.10,  pp .  10-16] 

The  following  comments  are  the  author's  comments  and 
opinion  concerning  the  interpretation  of  MIL-HDBK-61  and  MIL- 
STD-973.  These  opinions  were  formed  during  six  years  as  the 
Site  Manager  of  the  F/A-18  flight  simulator  software  support 
activity.  It  is  important  to  note  what  is  meant  by  software, 
both  in  MIL-HDBK-61  and  in  MIL-STD-973.  Configuration 
management  of  software  is  concerned  with  what  is  contained  on 
the  media  (whatever  that  media  is  such  as  tape  or  disk)  not 
the  media  itself.  Configuration  management  of  software 
involves  management  and  control  of  the  source  code  and  the 
executable  image  produced  as  a  result  of  linking  and  compiling 
source  code.  Configuration  management  of  software  also 
involves  management  of  the  documentation  for  that  software. 
Documentation  must  verify  that  the  binary  image  and  the 
documentation  are  consistent  and  at  the  same  level . 

Software  documentation  can  also  be  contained  in  the 
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source  code  used  to  generate  the  executable  image  and  this 
should  also  be  managed  as  a  complement  to  the  configuration 
management  effort.  Internal  source  code  documentation  such  as 
comments  added  to  the  source  lines  of  code  should  be  used  to 
identify  changes  and  change  requirements  to  the  code  and  thus 
comprise  an  element  of  configuration  management. 

This  is  mentioned  here  because  many  CM  efforts  involving 
software  are  aimed  at  controlling  the  media  upon  which  the 
software  is  contained.  Although  the  media  must  be  controlled 
and  is  also  a  component  of  software  configuration  management, 
it  is  not  the  primary  method  of  performing  software 
configuration  management.  The  key  element  is  in  managing  and 
controlling  the  executable  image  and  the  source  code  that 
generates  that  image. 

Of  all  the  elements  of  configuration  management 
(configuration  change  control,  configuration  identification, 
status  accounting,  and  FCA/PCA  audits)  configuration 
identification  can  easily  be  argued  as  the  most  important 
[Ref.  11,  sec.  4.1,  p.  21]  .  All  of  the  elements  of 
configuration  control  are  based  on  configuration 
identification.  If  a  configuration  is  not  properly  identified 
it  cannot  be  controlled. 

Configuration  identification  is  accomplished  at  three 
levels.  They  are: 

1.  Functional  Configuration  Identification  (FCI) . 

The  approved  functional  baseline  plus  approved  changes. 

2.  Allocated  Configuration  Identification  (ACI)  .  The 

approved  allocated  baseline  plus  approved  changes. 

3.  Product  Configuration  Identification  (PCI).  The 

approved  product  baseline  plus  approved  changes. 

The  composite  of  these  three  elements  constitutes  the  physical 
and  functional  configuration  identification. 
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8.  NASA  Technical  Memorandum  85908 


The  technical  tnemorandum  is  titled  "Software  Control  and 
System  Configuration  Management:  A  Systems-Wide  Approach." 
The  NASA  Ames  Research  Center  developed  a  CM  system  that 
encompasses  the  whole  of  a  system,  hardware  and  software,  in 
one  process.  The  information  in  this  section  is  a  compendium 
of  some  of  the  important  concepts  from  the  NASA  Technical 
Memorandum  85908  which  is  included  in  Appendix  E.  The  entire 
document  is  included  in  the  appendix,  even  though  it  is 
lengthy,  since  the  concepts  embodied  in  the  approach  to  CM 
are,  to  this  author,  important  for  future  consideration  of  an 
approach  to  CM  from  a  systems  concept. 

The  Summary  to  the  document  states: 

A  comprehensive  software  control  and  system 
configuration  management  process  for  flight- 
critical  digital  control  systems  of  advanced 
aircraft  has  been  developed  and  refined  to  ensure 
efficient  flight  system  development  and  safe  flight 
operations.  Because  of  the  highly  complex 
interactions  among  the  hardware,  software,  and 
system  elements  of  state-of-the-art  digital  flight 
control  system  designs,  a  systems -wide  approach  to 
configuration  control  and  management  has  been  used. 
Specific  procedures  are  implemented  to  govern 
discrepancy  reporting  and  reconciliation,  software 
and  hardware  change  control,  system  verification 
and  validation  testing,  and  formal  documentation 
reguirements .  An  active  and  knowledgeable 
configuration  control  board  reviews_  and  approves 
all  flight  system  configuration  modifications  and 
revalidation  tests.  This  report  includes  examples 
of  configuration  management  forms  and  a  description 
of  the  tracking  process  which  ensures  accurate  and 
consistent  records.  This  flexible  process  has 
proved  effective  during  the  development  and  flight 
testing  of  several  research  aircraft  and  remotely 
piloted  vehicles  with  digital  flight  control 
systems  that  ranged  from  relatively  simple  to 
highly  complex,  integrated  mechanizations. 

The  technical  memorandum  emphasizes  the  highly  complex 
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interactions  among  hardware,  software,  and  system  elements. 
The  solution  was  to  develop  a  "systems-wide"  approach  to 
configuration  control  and  management.  NASA's  experience  with 
the  use  of  separate  hardware  and  software  configuration 
control  procedures  was  shown  to  be  ineffective  for  highly 
integrated  systems,  such  as  digital  flight  control  systems. 
NASA  purports  that  the  use  of  their  systems-wide  approach  has 
been  very  successful  and  is  more  efficient  than  a  separate 
hardware  and  software  systems  approach. 

The  various  phases  of  system  development  are  described. 
They  include  definition  of  requirements,  design,  production, 
and  ground  and  flight  test.  It  is  important  to  recognize  that 
9-11  of  these  phases  are  likely  to  require  interactive 
development  over  the  life-span  of  system  and  this  is  critical 
to  implementing  a  good  configuration  management  process. 

To  properly  manage  these  phases  of  development,  an 
overall  system  configuration  management  process  is  needed  in 
order  to  provide  consistent  treatment  of  software  and  hardware 
elements.  This  process  addresses  both  software  and  hardware 
elements  of  advanced  integrated  systems  and  accommodates  the 
inherent  iterative  nature  of  advanced  digital  flight  control 
system  development.  The  concept  of  a  systems-wide  approach  to 
configuration  control  and  management  (which  means  that  the 
same  process  is  used  for  both  software  and  hardware  system 
elements)  is  a  primary  contributor  to  the  successful 
application  of  this  process  on  a  number  of  highly  complex 
aircraft  systems.  The  reader  is  invited  to  read  Appendix  E, 
NASA  Tech  Memo  85908,  System  Development  Phases,  p.  3  to  gain 
more  detailed  information  concerning  this  subject  and  related 
subjects  in  the  following  paragraphs. 

Documentation  provides  a  consistent  and  comprehensive 
method  for  documenting  developmental  changes.  The  primary 
goal  of  the  documentation  is  to  document  changes  implemented 
by  all  engineering  disciplines  involved  in  the  project. 
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In  the  section  labeled  Status  and  Tracking,  NASA  states 
that  an  efficient  method  of  tracking  progress  and  generating 
status  information  is  required  for  overall  project  management 
and  scheduling  purposes. 

The  reader  is  encouraged  to  read  the  entire  NASA 
Technical  Memorandum  to  gain  a  better  perspective  on  the 
details  of  the  systems-wide  approach  and  its  application  to 
several  projects.  This  sub- section  was  included  because  most 
of  the  systems  acquired  by  NAWCTSD  are  similar  in  nature  to 
those  described  in  the  NASA  Technical  Memorandum.  Integrated 
and  highly  interactive  hardware  and  software  systems  are 
common.  The  problems  addressed  by  NASA  are  similar  to 
problems  faced  by  NAWCTSD  in  the  implementation  of  CM  across 
a  wide  variety  of  systems . 

9.  NSTS  07700,  Voliime  IV,  Book  1,  Revision  G 

The  National  Space  Transportation  System  (NSTS)  07700 
(hereafter  referred  to  simply  as  the  NSTS  document  in  this 
thesis,  parts  of  which  are  included  in  Appendix  D)  provides 
the  CM  policy  for  the  space  shuttle  program  for  both  hardware 
and  software.  The  space  shuttle  program  is  also  called  the 
National  Space  Transportation  System  or  NSTS  as  in  the  title 
of  the  document.  The  following  paragraphs  present  the  major 
elements  of  CM  as  identified  in  the  NSTS.  The  reader  is 
invited  to  read  Appendix  D  in  order  to  obtain  more  details. 

The  NSTS  defines  the  requirements,  responsibilities,  and 
procedures  for  all  Space  Shuttle  Program  (SSP) 
elements/projects  in  the  application  of  configuration 
management  on  the  SSP  including  applicable  contractor 
activities . 

Configuration  identification  determines  the  manner  in 
which  requirements  for  configuration  is  described.  Formal 
documentation  developed  as  a  result  of  configuration 
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identification  is  used  to  describe  baselines  used  for  planning 
purposes  and  for  control  and  accounting  of  future  changes. 
Two  general  types  of  baselines  are  addressed,  the  "NASA 
baseline"  and  the  "design  activity/contractor  baseline."  The 
baselines  are  described  and  reference  is  made  to  the  baselines 
developed  as  the  program  matures  from  the  initial  baseline 
which  consists  of  program  management  and  system  performance 
baselines.  The  later  baselines  reflect  developmental  items. 
The  amount  of  information  contained  in  baselines  is  determined 
on  an  individual  basis. 

At  design  freeze  the  configuration  is  established  as 
verified  through  the  development  and  Orbital  Flight  Test 
phases  of  the  program.  Change  control  is  then  initiated  and 
baselines  are  expanded  to  include  production  drawings  and  the 
physical  and  functional  configuration. 

A  NASA  acceptance  baseline  is  developed  from  as-built 
configurations  of  the  flight  hardware  and  software.  A  Space 
Shuttle  program  baseline  is  developed  which  contains  program 
requirements,  Space  Shuttle  management  requirements,  system 
technical  requirements,  descriptive  documentation,  indentured 
parts  listings,  and  other  identification  documents  describing 
the  configuration  of  all  Space  Shuttle  hardware  and  software. 
A  list  of  the  types  of  data  contained  in  the  baseline  is 
included  in  Appendix  D,  par.  3.1.4,  p.  3-3.  These  items 
comprise  essential  elements  of  the  configuration  baseline. 

The  remainder  of  section  3  discusses  the  Space  Shuttle 
program  definition  and  requirements  baseline  documentation, 
preparation,  coordination,  and  processing  of  baseline 
documents,  and  interface  control  documents. 

Section  4.0  discusses  configuration  change  control.  It 
is  in  this  section  that  change  classifications  are  defined  and 
the  use  of  configuration  control  boards  (CCBs)  is  discussed. 
The  use  of  CCBs  in  performing  elements  of  CM  for  the  Shuttle 
Program  is  essential  to  NASA  CM  policy.  CCBs  are  responsible 
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for  approving  all  changes  to  shuttle  hardware  and  software . 
There  is  a  hierarchical  system  of  CCBs  in  place  to  assure  that 
both  programmatic  and  detailed  overview  of  changes  is 
accomplished . 

The  role  of  configuration  accounting  is  defined  and 
discussed.  Configuration  accounting  is  the  element  of  CM  that 
provides  the  essential  records  and  reporting  of  precise 
configuration  data  for  all  Space  Shuttle  hardware  and 
software.  The  configuration  accounting  system  maintains, 
stores,  and  correlates  the  accounting  data  including  change 
status  and  information.  The  system  produces  summaries  and 
comparisons  of  data  as  needed  for  individual  program  elements. 
The  control  of  interface  control  drawings  (ICDs)  is  discussed. 
The  role  of  the  contractor  or  developer  is  defined.  The  NASA 
system  allows  developers  to  determine  which  drawings  and/or 
ICDs  may  be  affected  by  a  proposed  change. 

The  Space  Shuttle  Program  uses  a  data  base  called  TDMS  2 
which  contains  current  and  historical  data  in  the  form  of 
Interface  Revision  Notices  (IRNs) .  This  data  base  allows 
integration  of  diverse  elements  across  the  spectrum  of 
projects,  developers,  and  Government  personnel  involved  in  the 
Shuttle  Program.  Other  configuration  status  reports  and 
reporting  requirements  are  identified.  Mission  essential 
software  data  retention  requirements  are  identified.  The 
software  is  required  to  be  retained  for  three  years. 

Part  6  of  NSTS  07700,  discusses  the  CM  of  requirements. 
It  includes  external  agency  requirements  and  interfacing 
requirements  between  program  elements  and  projects.  The  need 
for  reviews  is  discussed  and  it  is  stated  that  they  will  be 
conducted  "as  necessary."  Reviews  are  also  used  to  establish 
baselines . 
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10.  Attachment  01  to  Army  Contract  DAAH01-R-S079 


This  sub- section  is  included  and  Appendix  F  is  attached 
to  provide  an  example  of  the  approach  that  the  Army  Tactical 
Missile  System  (ATACMS)  project  manager  is  taking  with  respect 
to  CM  on  that  project.  The  reader  is  invited  to  read  Appendix 
F  to  better  understand  the  approach  the  Army  is  taking  with 
respect  to  CM  on  the  ATACMS  project. 

The  information  presented  in  Appendix  F  would,  prior  to 
the  Army's  streamlining  efforts  in  this  area,  have  occupied 
many  pages.  The  old  method  would  have  called  for  the 
application  of  standards  and  specifications.  The  functional 
specification  contained  in  Appendix  F  is  simple  and  concise. 
The  performance  specification  is  contained  in  MIS-38578 
Addendum  II  to  the  contract.  The  reader  is  invited  to  contact 
the  ATACMS  project  manager  if  a  copy  of  the  performance 
specification  is  desired. 

The  last  page  of  Appendix  F  is  a  copy  of  a  memorandum 
from  the  Army  Acquisition  Executive  which  addresses  the 
delivery  of  contract  data  items.  The  memo  requires  that  only 
one  copy  of  each  data  item  be  delivered  under  a  specified 
contract.  It  also  states,  "It  is  preferred  and  strongly 
encouraged  that  data  items  be  delivered  using  electronic 
media . " 

11.  IEEE  Standard  828-1983  for  Software  CM  Plans 

Although  this  standard  references  plans  rather  than 
policy,  the  author  felt  that  information  regarding  good 
software  CM  plans  was  important  in  understanding  the  part  CM 
plans  play  in  CM  policy  and  CM  policy  implementation. 

The  application  of  Software  Configuration  Management 
(SCM) ,  together  with  Hardware  Configuration  Management  (HCM) 
and  overall  systems  configuration  management,  benefits  all 
phases  of  the  life  cycle  of  a  system  containing  software 
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components  and  is  a  matter  of  good  engineering  practice  [Ref. 
12 ,  Forward] . 

Plans  document  the  methods  to  be  used  for  identifying 
software  product  items,  controlling  and  implementing  changes, 
and  recording  and  reporting  change  implementation  status  [Ref . 
12 ,  sec .  1.1,  p .  7]  . 

Software  Configuration  Management  Plan  implementation 
major  milestones  include  the  establishment  of  [Ref.  12,  sec. 
3.2.4,  p.  9]  : 

1.  The  configuration  control  board 

2 .  Each  configuration  baseline 

3 .  Schedules  and  procedures  for  SCM  reviews  and 
audits 

4.  Configuration  management  of  related  software 
development,  test,  and  support  tools 

This  paragraph  contains  information  in  the  IEEE  standard 
as  it  relates  to  implementing  CM  (or  SCM)  policy.  Also 
provided  in  this  information  are  examples  of  material  which 
may  be  covered  by  policies,  directives,  and  procedures  and  is 
therefore  important  to  understand  relative  to  overall  CM 
policy  recommendations  resulting  from  this  thesis. 

Applicable  policies,  directives  and  procedures  shall 
[Ref.  12,  sec.  3.2.5,  p.  9]: 

1.  Identify  all  applicable  SCM  policies,  directives, 
and  procedures  which  are  to  be  implemented  as  part  of 
this  plan.  The  degree  of  implementation  of  each  shall  be 
stated . 

2.  Describe  any  SCM  policies,  directives,  and 
procedures  that  are  to  be  written  and  implemented  for 
this  project. 

Examples  of  material  which  may  be  covered  by  policies, 
directives,  and  procedures  are  [Ref.  12,  sec.  3. 2. 5  (2): 
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1.  Identification  of  levels  of  software  in  a 
hierarchical  tree 

2 .  Program  and  module  naming  conventions 

3 .  Version  level  designations 

4.  Identification  of  specifications,  test  plans  and 
procedures,  programming  manuals,  and  other  documents 

5.  Media  identification  and  file  management 
identification 

6.  Document  release  process 

7.  Turnover  or  release  of  software  products  to  a 
library  function 

8.  Processing  of  problem  reports,  change  requests, 
and  change  orders 

9.  Structure  and  operation  of  configuration  control 

boards 

10 .  Release  and  acceptance  of  software  products 

11.  Operation  of  software  library  systems  to  include 
methods  of  preparing,  storing,  and  updating  modules 

12.  Auditing  of  SCM  activities 

13.  Problem  report,  change  request  or  change  order 
documentation  requirements  describing  purpose  and  impact 
of  a  configuration  change,  or  both 

14 .  Level  of  testing  required  prior  to  entry  of 
software  into  configuration  management 

15 .  _  Level  of  quality  assurance;  for  example 
verification  against  development  standards  required  prior 
to  entry  into  configuration  management 


This  list  includes  many  items  applicable  to  both  hardware  and 
software  configuration  and  thus  constitutes  a  list  of  possible 
essential  CM  policy  elements. 

For  each  change  control  board  and  other  change  management 
bodies  [Ref.  12,  sec.  3. 3. 2. 3,  p.  10]: 
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1.  Define  the  role  of  each;  for  example,  change 
review  authority 

2.  -  Specify  their  authority  and  responsibility 

3  .  Identify  the  chairperson  and  the  membership  in  the 
organizations,  if  the  organizations  have  been  formed 

4.  State  how  the  chairperson  and  the  members  (and 
alternates)  are  to  be  appointed,  if  the  organizations 
have  not  yet  been  formed 

5.  State  the  relationships  of  the  developers  and  the 
users  to  the  CCB{s) 

The  above  information  can  be  applied  to  hardware  CM  as  well  as 
software  CM  and  thus  represents  candidates  for  essential 
elements  of  CM  policy. 

State  the  methods  to  be  used  for  configuration  control  of 
interfaces  with  programs /pro j ects  beyond  the  scope  of  this 
software  configuration  management  plan.  If  the  software 
changes  are  required  to  be  reviewed  by  other  boards  or  teams 
prior  to  or  in  addition  to  the  CCB(s),  this  subsection  shall 
describe  these  board  (or  team,  or  both)  and  their  relationship 
to  the  CCB(s)  and  to  each  other.  [Ref.  12,  sec.  3. 3. 2. 4,  p. 
10] 

State  the  control  procedures  for  associated  special 
software  products,  such  as  non- released  software,  off-the- 
shelf  software,  user  furnished  software,  and  in-house  support 
software  [Ref.  12,  sec.  3. 3. 2. 5,  p.  11]. 

Identify,  state  the  purposes,  and  describe  (within  the 
developers  scope  of  proprietary  rights)  the  use  of  the 
specific  software  tools,  techniques,  and  methodologies  to  be 
employed  to  support  SCM  on  the  specific  project  [Ref.  12, 
sec .  3.4,  p .  11] . 
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B.  SUMMARY  OF  RESPONSES 


The  responses  to  interviews  conducted  by  the  author  of 
this  thesis  is  summarized  in  this  section.  The  interviews 
were  conducted  in  an  informal  manner.  Each  person  interviewed 
was  asked  what  they  felt  were  the  essential  elements  of  a  CM 
policy  and  were  invited  to  provide  answers  without  prompting. 
Additional  questions  were  asked  depending  upon  the  person 
interviewed  and  their  involvement  in  developing  CM  policy. 
Some  of  those  interviewed  were  also  asked  about  the  use  of  a 
Work  Breakdown  Structure  (WBS)  in  the  identification  of  CM 
items . 

All  interviews  except  those  conducted  at  NAWCTSD  itself 
and  at  the  Naval  Postgraduate  School,  were  conducted  over  the 
phone.  It  was  planned  that  most  of  the  information  to  be 
derived  from  the  comparable  industry  and  Government  sources 
would  be  derived  from  written  literature  sent  to  the  author. 
Such  was  the  case.  Facts  derived  from  written  material 
received  by  the  author  will  be  summarized  in  the  next  section. 

The  interview  with  NAWCTSD  personnel  revealed  that  there 
was  concern  that  CM  was  not  uniformly  implemented  across  the 
broad  spectrum  of  devices  supported.  The  author  interviewed 
personnel  involved  in  developing  and  maintaining  the 
Configuration  Management  Information  System  (CMIS)  at  NAWCTSD. 
The  same  personnel  were  tasked  to  write  the  upgraded 
NAWCTSDINST  4130. _M  and  will  also  have  input  to  the 
development  of  the  NAWCTSD  CM  policy  statement  in  its  final 
form.  Other  personnel  interviewed  were  Project  Directors  and 
the  Department  Head  and  Deputy  Department  Head  of  Competency 
3.0,  the  logistics  support  competency.  The  following 
paragraphs  summarize  their  answers  to  questions  and  also 
provides  data  that  was  provided  ad  hoc  to  the  author  of  this 
thesis  during  the  interviews . 
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1 .  NAWCTSD  MANAGEMENT 


The  Competency  3.0  Department  Head  and  his  Deputy  had  an 
appropriately  long  term,  strategic  outlook  on  the 
implementation  of  CM  and  the  development  of  a  good  CM  policy 
at  NAWCTSD.  They  were  also  appropriately  concerned  with 
systems  for  the  life-cycle  of  the  system  rather  than  just 
during  acquisition.  They  discussed  CM  in  the  "out  years" 
(years  beyond  the  acquisition  phase  for  Cognizance  2"0" 
systems)  and  they  felt  that  a  study  would  have  to  be  done  to 
address  the  issue  of  long  term  CM  support.  They  identified 
the  following  areas  of  interest  as  potential  study  questions. 
These  questions  identify  their  concerns  for  CM  implementation 
and  CM  policy,  and  also  suggest  study  topics  for  this  thesis 
and  for  possible  future  studies  of  a  similar  nature: 

•  What  do  we,  NAWCTSD,  want  to  achieve  in  the  area  of  CM? 

•  To  what  level  do  we  want  CM  accomplished  on  a  given 
system  or  on  the  broad  base  of  systems  supported? 

•  What  architecture  should  be  recommended  or  required? 

•  Who  are  the  customers  for  CM  results,  data,  baselines, 
and  information,  both  internal  and  external? 

•  What  other  organizations  are  successfully  performing  CM 
and  what  is  their  policy? 

•  What  is  the  role  of  the  field  (ISEOs)  and  other 
competencies  in  the  implementation  of  effective  CM 
policy  for  NAWCTSD? 

•  What  automated  equipment  should  be  employed  in 
performing  CM? 

2.  NAWCTSD  CM  PERSONNEL 

Personnel  involved  in  writing  and  implementing  CM  policy 
at  the  branch  level  at  NAWCTSD  were  interviewed  to  determine 
their  view  of  the  challenges  presented  in  implementing  CM. 
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Following  is  a  summary  of  their  comments  and  concerns. 

The  CMIS  system  was  developed  as  a  local  effort  of 
NAWCTSD.-  It  has  served  the  purpose  for  which  it  was 
developed,  primarily  to  serve  as  a  repository  for  CM 
information  in  support  of  the  TECCB,  but  has  not  kept  pace 
with  technology  in  the  area  of  data  base  design.  It  is 
difficult  to  modify  this  data  base  to  perform  additional 
functions  as  demanded  by  both  internal  and  external  customers . 
One  of  the  major  tasks  faced  by  personnel  involved  with  the 
CMIS  was  to  either  modify  it  to  meet  new  requirements  or  to 
recommend  the  development  of  an  alternative  Configuration 
Management  Information  System.  A  new  system  would  be  costly 
and  would  require  time  to  develop  and  get  on  line.  This 
information  is  provided  simply  to  provide  a  more  complete 
picture  of  the  challenges  and  their  priority  at  NAWCTSD  in 
developing  a  comprehensive  CM  policy  including  the  systems  and 
personnel  needed  to  assure  that  the  system  will  function  now 
and  in  the  future . 

On  the  surface,  information  concerning  the  CMIS  system 
does  not  appear  to  be  relevant  to  the  development  of  CM  policy 
for  NAWCTSD.  However,  personnel  involved  in  implementing  that 
policy  place  the  development  of  facilitating  tools  at  a  high 
priority  in  their  work.  The  development  of  a  CM  policy  at 
NAWCTSD  is  not  dependent  upon  any  particular  type  of  system 
employed  to  perform  the  tasks  to  be  determined,  but  whatever 
system  is  employed  will  be  a  factor  in  the  success  of  any 
policy  that  is  developed.  Therefore,  this  information  is 
germane  to  the  development  of  policy  since  it  is  of  great 
concern  to  those  involved  and  will  contribute,  ultimately  to 
the  success  of  the  policy  implemented.  This  thesis  will  not 
attempt  to  recommend  that  any  particular  CMIS  system  be  used 
at  NAWCTSD  but  will  assume  that  a  satisfactory  system  is  in 
place  to  support  the  goals  of  the  resulting  policy. 

Other  concerns  of  the  personnel  "in  the  trenches"  was 
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that  whatever  policy  was  developed,  it  had  to  account  for  the 
diversity  of  the  customer  data  base,  both  internal  and 
externaL.  And,  that  it  should  be  written  in  unambiguous  terms 
to  assure  the  same  interpretation  by  all  personnel  involved  in 
CM.  They  want  the  policy  to  clearly  define  responsibility  and 
to  clearly  define  governing  instructions. 

The  problem  of  who,  that  is  exactly  which  competencies 
within  NAWCTSD,  will  perform  what  functions  is  important  to 
the  personnel  interviewed.  This  is,  apparently,  a  long  term 
question  to  be  resolved  and  one  which  this  thesis  may  only 
partially  answer. 

Other  concerns  of  the  personnel  interviewed  were  of  a 
specific  nature  concerning  CM  as  it  is  practiced.  The 
concerns  were  at  a  level  which  this  thesis  will  not  attempt  to 
answer  and  therefore,  those  comments  are  not  summarized  here. 

3.  Army  TACMS  (ATACMS)  PROJECT  MANAGER 

The  past  ATACMS  project  manager  was  interviwed.  He  is 
now  a  Senior  Guest  Lecturer  at  the  Naval  Postgraduate  School . 
When  asked  what  the  Army  CM  policy  was  for  the  ATACMS  system 
it  was  stated  that  CM  was  done  by  the  contractor  with 
Government  control  (chairmanship)  of  the  Change  Control  Boards 
(CCBs) .  The  project  manager  (PM)  is  a  member  of  the  CCB  for 
life.  This  is  how  the  Government  maintains  control  of  the 
system  configuration.  Prime  contractors  with  sustaining  funds 
have  continuity  and  can  thus  perform  CM  best  for  the  life 
cycle  of  the  system. 

The  following  paragraphs  summarize  ad  hoc  comments 
concerning  CM  and  CM  policy. 

The  weakest  part  of  the  CM  effort  was  in  performing  good 
physical  configuration  audits  (PCAs) .  The  second  PCA  that  was 
performed  on  the  emergent  system  was  done  incrementally  (in 
pieces,  in  a  controlled  fashion) .  This  method  delivered 
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better  results  than  the  first  effort. 

A  good  CM  plan  is  essential  to  the  acquisition  and  life- 
cycle  support  of  the  system  (of  any  system) .  The  advent  of 
the  Computer-aided  Acquisition  and  Logistics  System  (CALS) , 
when  fully  implemented,  will  help  improve  our  (Government  and 
contractor)  CM  efforts. 

During  the  interview  the  author  was  presented  with  and 
discussed  the  contents  of  several  handouts.  Following  is  a 
brief  summary  of  the  CM  related  issues  discussed  and  contained 
in  those  handouts: 

•  Logistician (s)  must  influence  the  CM  plan,  change 
control  process,  and  program  funding  to  maintain  PM- 
owned  equipment  in  most  current  production 
configuration.  (This  equipment  is  frequently  used  to 
support  engineering  services  during  the  production  and 
deployment  phase . ) 

•  Logistician  (s)  must  ensure  that  the  CM  plan  imposes 
change  control  on  all  common-use  manufacturer's  tooling 
and  Software  Test  Equipment  (STE)  and  Automatic  Test 
Equipment  (ATE) . 

4.  ATACMS  Configuration  Manager 


Following  is  a  summary  of  discussion  and  ad  hoc  comments 
provided  during  a  telephone  interview  with  the  ATACMS  CM 
manager . 

CM  policy  for  the  ATACMS  is  different  today  than  it  was 
just  a  few  months  ago.  The  Perry  Memorandum  [Ref.  1]  has 
changed  the  way  the  ATACMS  program  is  doing  business. 
Following  is  a  summary  of  comments  concerning  this  issue: 

•  No  "how-tos"  only  "what-tos"  in  contractual  documents. 

•  The  Army  Acquisition  Executive  (AAE)  is  adamant  that 
PMs  limit  use  of  military  standards  and  specifications. 
(See  Appendix  F) 

•  PMs  are  to  use  only  functional  or  performance 
specifications  not  military  specifications  or 
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standards.  (See  Appendix  F  for  an  example) 

•  The  part  of  the  ATACMS  Statement  of  Work  (SOW)  that 
addressed  CM  used  to  be  very  specific  and  was  contained 
on  many  pages.  It  is  now  not  specific  and  is  contained 
on  less  than  one-quarter  of  a  page.  It  says  what  we 
want  from  the  contractor,  not  how  we  want  the 
contractor  to  do  CM.  (See  Appendix  F) 

•  In  the  instructions  to  bidder,  the  word  "plan"  is  out. 
The  words  "technical  approach"  are  preferred  including 
the  contractor's  technical  approach  to  CM. 

•  The  Government  used  to  be  carried  away  with  format, 
that  is  not  so  now. 

•  The  contractor's  technical  approach  will  include  a  CM 
technical  approach. 

•  The  ATACMS  program  will  no  longer  use  ECPs  as  a  measure 
of  performance. 

•  The  contractor  should  still  have  the  same  type  of 
information  necessary  to  accomplish  CM  in  the  technical 
approach,  in  fact,  they  may  still  use  one  of  the 
military  standards  such  as  MIL-STD-973. 

The  ATACMS  plan  is  to  do  Physical  Configuration  Audits 
(PCAs)  and  Functional  Configuration  Audits  (FCAs)  as  a  team 
effort  with  the  contractor.  One  of  the  lead  team  members  will 
be  the  Defense  Plant  Representative  Office  (DPRO) 
representative  who  will  be  on  the  team  from  the  beginning  of 
the  acquisition  until  the  end. 

It  is  important  to  determine  the  baseline  while  building 
the  product  instead  of  attempting  to  determine  the  baseline 
after  the  product  is  built  using  a  PCA/FCA. 

The  Work  Breakdown  Structure  (WBS)  should  be  used  to 
establish  a  configuration  breakout  of  the  system.  Care  should 
be  exercised  since  this  is  a  contractually  controlled  item  and 
may  not  be  the  same  for  all  programs .  The  level ,  detail ,  and 
other  items  may  differ  and  may  not  provide  adequate 
decomposition  of  the  system  to  accommodate  CM  requirements . 

The  contractor  must  have  drawings  under  a  CM  system. 
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The  Government  needs  some  type  of  automatic  data  access 
to  the  contractor's  data  on  the  project.  Ultimately,  the 
ATACMS  CM  manager  would  like  to  have  the  same  exact  data  base 
that  the  contractor  is  maintaining.  The  Government  should  let 
the  contractor  know  what  the  Government  needs  and  have  the 
contractor  build  the  data  base  and  access  to  the  data  in  the 
data  base.  It  could  be  that  the  Government  could  have 
automatic  uploads  of  data  from  the  contractor  based  on  needs. 

As  companies  automate  and  get  CALS  compliant,  the  cost  of 
doing  business  should  decrease.  The  initial  cost  of  becoming 
CALS  compliant  should  then  be  reduced  to  reflect  this 
decreasing  cost  as  the  project  progresses.  The  Government 
should  leverage  this  to  keep  the  initial  cost  of  "going  CALS" 
to  a  minimum. 

5.  Loral  Corporation,  Manager,  Space  Shuttle  Project 
Coordination 

Following  is  a  summary  of  responses  to  questions 
concerning  Loral's  CM  policy  for  its  Shuttle  Software  Support 
Operations  in  Houston,  TX.  Appendix  G  contains  two  sections 
from  Loral's  "Space  Shuttle  Onboard  Software  Program 
Management  and  Control  Process . "  These  sections  provide 
additional  information  to  that  provided  below. 

Loral  has  a  CM  policy,  but  it  is  not  written  as  an 
overall  CM  policy  for  Loral.  CM  is  totally  ingrained  in  the 
entire  process  of  software  development  and  in  everything  they 
do  in  support  of  the  Shuttle  software.  In  fact,  it  is 
critically  important  to  the  CM  effort,  that  the  process  itself 
be  under  CM,  as  it  is  at  Loral. 

Loral  has  a  mature,  documented  software  development 
process .  It  was  developed  with  NASA' s  involvement  and  was 
recently  rated  at  a  Capability  Maturity  Model  level  five  by  a 
NASA  team  trained  to  perform  software  assessments  at  the 
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Carnegie  Mellon  University,  Software  Engineering  Institute. 
In  December  of  1994,  the  project  received  an  unconditional 
International  Standards  Organization  (ISO)  9000  certification. 

Loral  does  not  do  hardware  configuration  for  the  shuttle 
program.  Hardware  information  that  impacts  software  (extant 
or  in  development)  at  Loral,  is  passed  to  Loral  from  the  CCB 
(NASA  CCB  with  the  hardware  contractor  as  a  member  of  the 
board)  . 

Loral  does  not  use  an  automated  CM  system  in  the 
development  of  Shuttle  software.  One  reason  is  that  the 
process  was  started  in  the  1970s  before  good  Computer  Aided 
Software  Engineering  (CASE)  tools  were  available.  Also,  Loral 
uses  HAL,  a  custom  language  developed  by  Loral.  They  also  use 
a  locally  developed  CM  system. 

6 .  NASA  Shuttle  Hardware  CM  Manager 

Following  are  general  comments  concerning  the  most 
important  elements  of  hardware  CM  as  practiced  by  NASA  on  the 
shuttle.  When  asked  if  there  was  a  written  overall  or  policy 
statement  it  was  stated  that  CM  policy  was  a  derivative  of  DoD 
policy  tailored  to  NASA's  needs.  Their  policy  is  contained  in 
the  NASA  Space  Transportation  System  07700,  Volume  IV,  Book  1, 
Revision  G  (see  Appendix  D)  .  The  following  paragraphs  contain 
information  provided  on  an  ad-hoc  basis  concerning  essential 
elements  of  CM  policy. 

The  project  manager  maintains  authority  over  delivered 
hardware.  This  is  what  "drives"  the  system. 

CCBs  meet  daily  to  control  all  changes. 

Communication  is  required  between  shuttle  hardware  and 
software  groups  in  order  to  assure  that  changes  made  to  either 
are  both  known  and  controlled. 

Most  of  the  CM  work  is  done  by  the  various  hardware 
contractors.  For  the  shuttle  space  system,  they  maintain  just 
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one  data  base.  The  engine  and  tank  CM  data  base  is  separate. 
They  recommend  one  central  data  base  if  at  all  possible,  with 
input  direct  from  the  contractor  or  that  the  contractor 
provide  the  data  base  and  give  access  to  the  Government. 

For  any  new  undertakings,  an  automated  CM  system  should 
be  required.  For  older  systems  it  is  not  economically  viable 
to  change  from  a  manual  system  to  an  automated  system. 

7 .  NASA  Shuttle  Software  CM  Manager 

When  asked  if  NASA  had  a  written  or  overall  CM  policy  the 
reply  was  that  the  policy  was  contained  in  multiple  documents 
that  implement  CM  for  the  Shuttle.  However,  the  document 
included  in  Appendix  D  is  for  the  Shuttle  Space  Program  and 
presents  an  overall  policy.  Contractors  do  most  of  the  CM  on 
the  shuttle.  NASA  has  members  on  or  chairs  multiple  CCBs  to 
control  the  requirements  and  thus  the  configuration  of  each 
Shuttle  since  each  one  that  flies  is  different  in  many  ways 
from  the  last. 

Policy  is  also  contained  in  multiple  software  and 
hardware  management  plans.  The  purpose,  scope,  definitions, 
and  phases  of  software  management  are  contained  in  the  CM 
plans  implemented  as  a  result  of  the  NSTS  07700  document  (see 
Appendix  D)  .  Contractor  CM  plans  are  important  in  determining 
overall  Shuttle  CM  policy.  They  may  indeed,  be  the  backbone 
of  CM  policy  for  NASA,  not  withstanding  the  NASA  Technical 
Memorandum  85908  referenced  in  this  thesis  and  the  NSTS  07700 
included  in  Appendix  E  which  is  specific  to  the  Shuttle 
Program . 

Hardware  changes  are  evaluated  for  software  impact  by 
"smart"  hardware  engineers,  both  within  NASA  and  by  their 
contractors .  When  a  hardware  change  impacts  software  the 
software  personnel  are  asked  to  look  at  the  change  that  is 
being  proposed.  If  software  personnel  agree  that  a  change  is 
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necessary,  the  information  goes  to  a  CCB  for  approval  and 
scheduling.  This  direct  infomation  exchange  system  ties  the 
hardware-  system  to  the  software  system  and  integrates  the  CM 
systems  of  both. 

8.  NFS  Professors 

The  following  information  is  an  integration  of  comments 
received  from  two  professors  at  the  NFS.  Both  professors  are 
members  of  the  Information  Systems  Engineering  and  Management 
Group  in  the  Systems  Management  Department.  One  teaches 
Software  Configuration  Management  and  has  done  studies  for  the 
NASA  Shuttle  project.  The  other  teaches  Management 
Information  Systems  and  is  expert  in  the  principals  of  CM  as 
practiced  in  industry  and  the  Government. 

One  professor  felt  that  the  use  of  a  WBS  in  developing  a 
CM  policy  for  systems  is  preferred  mostly  by  high  level  civil 
servants  to  aid  in  metrics  for  measuring  system  costs  and  for 
describing  the  system  at  a  high  level .  It  can  be  of  aid  in 
developing  a  CM  system  but  care  must  be  used  in  trying  to 
adapt  it  to  CM  use.  It  is  used  primarily  for  identifying 
costs  and  therefore  may  not  be  an  optimum  decomposition  of  the 
system  for  purposes  of  CM. 

They  recommended  the  use  of  automated  CM  tools  as  much  as 
is  practicable  within  program  constraints  (dollars)  .  It  would 
be  best  to  use  some  standard  in  requiring  an  automated  system, 
but  we  should  not  specify  any  particular  system.  The  best 
approach  is  to  use  standard  data  elements  to  assure  that  all 
projects  provide  the  necessary  configuration  management 
information  to  the  level  desired. 

CCBs  should  have  Government  members  on  them  or  should  be 
chaired  by  a  Government  member.  A  discrepancy  control  board 
should  be  established.  Absolutely  all  changes  to  the  system 
must  be  documented  including  requirements  for  the  changes. 
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All  documents,  organizations,  people,  and  requirements 
should  be  traceable  from  program  inception  to  disposition  of 
the  syst-em  at  the  end  of -its  useful  or  supportable  life. 

CM  policy  should  be  developed  early  in  the  program.  We 
must  determine  exactly  what  we  are  trying  to  manage  when 
determining  the  composition  of  a  CM  system.  We  should  manage 
and  define  all  interfaces  in  the  system  as  well  as  discreet 
system  elements.  We  should  manage  specifications  (as 
applicable  in  the  new  acquisition  environment) .  We  should 
manage  both  hardware  and  software. 

There  must  be  both  a  •  functional  and  physical 
decomposition  of  the  system. 

The  decision  process  must  be  identified  and  managed.  We 
must  also  know  exactly  what  data  we  need. 
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VI.  ANALYSIS 


The  derivation  of  answers  to  the  research  questions  are 
a  product  of  deduction  and  induction  and  represent  a  whole 
derived  from  many  different  parts .  This  thesis  is  structured 
to  provide  answers  specific  to  the  needs  of  NAWCTSD  with 
respect  to  an  over-arching  CM  policy  thus  is  broad  in  scope. 
Individual  competencies  within  NAWCTSD  may  find  the  answers 
too  broad  to  assist  them  in  implementing  the  resultant  policy. 
For  those  individuals,  it  is  recommended  that  they  study  the 
references  in  this  thesis  with  an  emphasis  on  military  and 
commercial  standards  for  more  specific  information  concerning 
implementation  at  the  working  level . 

A.  ESSENTIAL  ELEMENTS  OF  CM  POLICY 

There  is  general  agreement  by  the  sources  studied  for 
this  thesis  that  CM  comprises  four  major  elements.  They  are 
[Ref:  13,  p.  vi-vii] : 

1.  Configuration  Identification.  Selection  of  the 
documents  which  identify  and  define  the  configuration 
baseline  characteristics  of  an  item. 

2.  Configuration  Control.  Controlling  changes  to  the 
configuration  and  its  identification  documents. 

3.  Configuration  Status  Accounting.  Recording  and 
reporting  the  implementation  of  changes  to  the 
configuration  and  its  identification  documents. 

4.  Configuration  Audit.  Checking  an  item  for  compliance 
with  the  configuration  identification. 

This  definition  is  in  concert  with  the  definition  provided  in 
DoD  5000.2  and  other  instructions,  but  it  is  provided  in  terms 
that  are  clear  and  perhaps  more  easily  understood.  It  is 
provided  in  this  chapter  to  identify  clearly  the  major 
elements  of  CM.  The  reader  is  invited  to  compare  this 
definition  with  that  provided  in  Appendix  C  (from  NAWCTSDINST 
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4130. _M)  which  includes  the  same  elements  but  is  in  more 
technical  terms.  The  definition  in  Appendix  C  also  addresses 
digital  -  data  files.  It  is  the  same  as  that  found  in 
NAVAIRINST  4130. 1C.  The  importance  of  the  definition  found  in 
Appendix  C  versus  that  provided  above  is  that  the  present 
policy  of  NAWCTSD  is  in  consonance  with  technical  treatises  as 
well  as  the  definition  of  CM  in  NAVAIRINST  4130. 1C.  The 
bottom  line  is  that  CM  policy  must  address  these  four  areas  as 
well  as  the  additional  area  of  digital  data  files  which  is  not 
included  in  the  list  of  CM  elements  above. 

B.  CM  REQUIREMENTS  PER  DoN,  DoD,  AND  OTHER  FEDERAL 
REGULATIONS 

In  order  to  discuss  DoN,  DoD,  and  other  federal 
requirements  it  is  important  to  establish  which  instructions 
are  superior.  For  purposes  of  this  thesis  NAVAIR  is  the 
governing  agency  which  determines  CM  requirements  and  thus  CM 
policy  for  NAWCTSD.  There  are  no  conflicting  instructions 
regarding  CM  policy  and  implementation. 

The  author  found  NAVAIRINST  4130. 1C  to  be  a  comprehensive 
document  which  references  SECNAVINST  4130.2  a  superior 
instruction,  hierarchically,  which  requires  NAVAIR  to 
establish  CM  policy,  procedures,  and  guidance  in  processing 
engineering  changes . 

Department  of  Defense  Instruction  5000.2  was  not  listed 
in  the  list  of  references  in  the  cover  letter  to  NAVAIRINST 
4130. 1C.  It  is,  however,  the  basis  for  Appendix  D  in 
NAVAIRINST  413  0. 1C  which  provides  information  concerning  CM  of 
mission-critical  computer  software.  DoDI  5000.2  is  referenced 
in  NAVTRASYSCENINST  4130.3  governing  CM  policy  at  NAWCTSD. 
Because  of  the  importance  of  DoDI  5000.2  in  determining 
acquisition  policy,  a  part  of  which  includes  CM,  that 
information  is  integrated  into  the  following  analyses. 

The  general  policies  embodied  in  NAVAIRINST  4130. 1C  will 
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be  relied  upon  to  clearly  establish  the  requirements  for  CM 
policy  for  NAWCTSD.  Other  elements  may  be  determined  to  be 
requiredr  in  order  to  define  a  more  comprehensive  policy  than 
that  required  in  NAVAIRINST  4130. 1C.  The  elements  contained 
in  NAVAIRINST  4130. 1C  are  minimum  requirements  for  CM.  Those 
items  not  covered  in  NAVAIRINST  4130. 1C  but  which  are  included 
in  DoDI  5000.2  and  other  documents  studied,  are  discussed  as 
appropriate  in  this  and  subsequent  sections. 

NAVAIRINST  4130. 1C  addresses  requirements  for  the 
aviation  community.  Since  NAWCTSD  serves  other  customers 
outside  the  NAVAIR  arena,  other  .requirements  may  result  from 
instructions  extant  at  those  outside  agencies.  Since  those 
requirements  may  be  dynamic  and  may  differ  from  those 
contained  in  NAVAIRINST  4130. 1C,  it  is  outside  the  scope  of 
this  thesis  to  address  them  individually.  However,  the 
implementation  of  CM  based  upon  DoDI  5000.2  and  other  military 
standards  assures  that  other  military  agencies  have  derived  CM 
requirements  from  at  least  some  of  the  same  documents  used  to 
derive  the  requirements  for  CM  in  NAVAIRINST  4130. 1C.  The  CM 
policy  for  NAWCTSD,  part  of  which  is  embodied  in  CM  plans,  may 
be  modified  as  necessary  to  meet  the  needs  of  other  agencies 
including  those  outside  DoD. 

NAWCTSD  is  designated  an  Office  of  Primary  Responsibility 
(OPR)  [Ref:  14,  par.  6,  p.  4].  Chapter  V,  page  9,  of  this 
thesis,  lists  the  CM  responsibilities  for  an  OPR.  That  list 
of  seven  items  represents  the  overall  requirements  of  CM  for 
an  OPR  and  thus  the  minimum  essential  elements  of  CM  policy 
for  the  NAWCTSD.  Those  requirements  are  not,  however, 
inclusive  of  all  of  the  elements  that  exist  in  DoN,  DoD  and 
other  Federal  Government  regulations  some  of  which,  analysis 
indicates,  should  be  included  as  essential  elements  in  the 
resulting  CM  policy  for  NAWCTSD. 

The  following  paragraphs  will  list  the  seven  items 
individually  and  will  analyze  the  content  of  each  for 
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applicability  to  CM  policy  at  NAWCTSD.  The  seven  items  cover 
the  essential  elements  of  CM  policy  as  identified  in  paragraph 
A.  Other  potential  essential  CM  elements  will  be  analyzed  in 
subsequent  paragraphs . 

1.  OPRs  are  responsible  for  providing  CM  of  assigned  CIs 
throughout  their  life-cycle.  To  implement  this  as  policy  it 
is  necessary  to  define  CM  and  to  determine  what  should  be  the 
defined  life-cycle.  Configuration  Management  is  defined  in 
NAVAIRINST  4130. 1C.  That  definition  is  in  agreement  with 
other  definitions  in  technical  documents  concerning  CM  such  as 
the  "Military  Project  Management  Handbook."  Appendix  C  lists 
the  definition.  Also  included  in  the  definition  is  the 
definition  of  how  CM  is  applied  to  digital  data  files. 

The  life-cycle  of  a  system  or  Cl  is  defined  in  DoD 
5000.2.  The  life-cycle  of  systems  is  defined  in  phases 
beginning  with  the  Concept  Exploration  and  Definition  phase 
and  ending  with  disposition  of  the  system  at  the  end  of  the 
Operations  and  Support  phase.  Specific  CM  requirements, 
source  documents,  and  baselines  for  individual  phases  are 
listed  in  Chapter  V  of  this  thesis  and  in  NAVAIRINST  4130. 1C, 
paragraph  1.4,  p.  1-1 .  A  comprehensive  CM  policy  would 
include  the  information  necessary  to  identify  CM  requirements 
during  each  phase  of  the  system's  (CIs)  life-cycle.  Other 
technical  documents  studied  are  in  general  agreement  with  the 
phases  and  their  requirements  listed  in  NAVAIRINST  4130. 1C. 
Whether  a  system  is  acquired  by  NAWCTSD  or  is  inducted  into 
the  NAWCTSD  inventory,  CM  policy  establish  minimum  CM 
requirements.  Differences  may  exist  based  on  CM  systems 
established,  or  not  established,  in  the  acquisition  phase  of 
the  system  inducted  into  the  NAWCTSD  inventory. 

All  documentation  analyzed  indicates  that  CM  should  be 
started  as  early  as  possible  in  the  acquisition  phase  and 
should  be  continued  for  the  life-cycle  of  a  system.  CM  should 
be  an  integral  part  of  the  development  of  both  the  software 
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and  hardware.  Software  is  given  special  treatment  both  in 
NAVAIRINST  4130. 1C  and  in  the  other  technical  documents 
researched.  A  comprehensive  CM  policy  should  state  the 
requirements  for  contractors  to  perform  CM  on  software  in 
accordance  with  DoD-STD-2167A,  Section  4.5.2,  p.  17  and  as 
listed  in  Chapter  V  of  this  thesis.  It  is  important  to 
recognize  that  CM  on  software  should  start  early  in  the 
acquisition  phase  and  that  is  why  DoD-STD-2l67A  should  be 
identified  clearly  in  a  comprehensive  CM  policy. 

DOD-STD-2167A  addresses  CM  from  the  contractor  viewpoint 
and  it  is  the  contractor  who  will  establish  CM  early  in  the 
acquisition  phase,  not  the  Government.  It  is  recognized  and 
stated  in  NAVAIRINST  4130. 1C  and  in  DoD-STD-2167A  that 
standards  are  to  be  tailored  as  necessary  to  accomplish  CM  on 
a  given  system. 

Software  CM  requirements  must  clearly  establish  what  is 
to  be  managed  with  reference  to  source  code  and  the  executable 
image.  This  will  assure  that  contractors  approach  software  CM 
efforts  with  a  goal  that  correctly  mirrors  the  requirements  of 
the  Government.  Hardware  CM  requirements  must  also  establish 
clearly  what  is  to  be  managed.  Configuration  identification 
is  considered  one  of  the  most  important  CM  requirements  for 
both  hardware  and  software  CM.  If  done  properly  CM  will  be 
more  successful  since  what  is  to  managed  will  be  clearly 
documented  and  understood  by  all  implementers . 

2.  OPRs  are  responsible  for  preparing  and  maintaining  CM 
plans  for  assigned  CIs,  obtaining  approval  of  these  plans,  and 
assuring  proper  implementation  of  NAVAIRINST  4130. 1C. 
NAVAIRINST  4130. 1C  requires  that  a  CM  plan  be  written  for  each 
Cl  under  the  cognizance  of  an  OPR.  NAWCTSD  has  many  CIs  under 
its  cognizance  and  therefore  an  umbrella  CM  plan  is 
appropriate  to  cover  this  requirement  [Ref:  7,  par.  2.2.2,  p. 
2-2]  . 

Reference  is  made  to  IEEE  Standard  828-1983  for 


65 


information  specific  to  implementing  CM  plans  for  software. 
Applicable  policies,  directives,  and  procedures  are  identified 
and  a  list  is  provided  of  examples  of  material  which  may  be 
covered  by  policies,  directives,  and  procedures  [Ref:  12, 
section  3.2.5]  It  is  the  author's  opinion  that  the  material 
referenced  in  the  IEEE  Standard  and  in  NAVAIRINST  4130. 1C,  as 
discussed  in  Chapter  V  of  this  thesis,  form  the  backbone  of  a 
comprehensive  CM  policy  for  software,  tailored  as  necessary 
for  individual  programs . 

To  cover  individual  CIs,  a  separate  addendum  may  be 
prepared  to  explain  and  tailor  policies  and  procedures  to  be 
followed  to  accomplish  CM  on  an  individual  Cl.  If  the  Cl  is 
for  an  organization  outside  the  DoD,  it  is  the  author's 
opinion  that  tailoring  may  have  to  be  more  substantial  than 
for  CIS  falling  under  the  DoD  umbrella.  However,  this  should 
not  require  an  additional  CM  plan  to  be  written  just  for  those 
CIS.  An  addendum  to  the  umbrella  CM  plan  will  suffice  to 
tailor  the  plan  to  a  specific  Cl  outside  the  DoD  purview.  CM 
plans  for  surface  and  sub- surface  communities  of  the  Navy 
which  are  serviced  by  NAWCTSD  will  require  less  tailoring  of 
the  umbrella  CM  plan  but  most  likely  require  some  tailoring. 

Overall  CM  policy  must  address  situations  where  more  than 
one  Government  agency  is  involved  in  the  development, 
acquisition,  modification,  or  support  of  a  Cl .  This  requires 
that  a  mutually  approved  CM  plan  be  included  as  part  of  the 
program  interface  document.  [Ref:  7,  par.  1.5,  p.  1-2]  CM 
policy,  in  order  to  be  comprehensive  should  include  provisions 
for  joint  endeavors.  The  policy  can  be  included  in  the  CM 
policy  document  by  reference  to  the  appropriate  section  of 
NAVAIRINST  4 130. 1C. 

The  CM  policy  must  also  address  support  for  systems 
inducted  into  the  NAWCTSD  inventory  which  were  not  acquired  by 
NAWCTSD.  Systems  in  this  category  will  have  to  be  surveyed  to 
determine  the  extent  of  CM  support  developed  during  the 
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acquisition  phases.  Systems  in  this  category  will  depend  upon 
resources  available  to  develop  or  sustain  CM.  They  will,  of 
course,  -have  to  be  supported  in  the  same  manner  as  other 
systems  within  the  constraints  introduced  by  available 
resources . 

3 .  OPRs  are  responsible  for  managing  and  providing 
direction  for  the  staffing  of  all  engineering  change 
proposals,  RAMECs,  and  requests  for  major  and  critical 
deviations  and  waivers  from  initiation  until  submittal  to  a 
CCB.  This  requirement  is  thoroughly  documented  in  NAVAIRINST 
4130. 1C  and  requires  no  significant  analysis  to  implement. 
Questions  related  to  this  requirement  are  answered  in  the 
appropriate  sections  of  Chapter  V  and  in  NAVAIRINST  4130. 1C. 
Forms  are  provided  in  NAVAIRINST  4130. 1C.  Explanations  for 
completing  them  and  the  process  for  routing  them  are  clearly 
defined  in  NAVAIRINST  4130. 1C,  Chapter  6.  Analysis  of  the 
instruction  indicates  that  the  process  can  be  used  without 
modification  by  NAWCTSD  except  for  systems  not  under  the 
purview  of  NAVAIR.  Those  systems  should  be  adaptable  to 
NAVAIRINST  4130. 1C  with  minor  modification  to  suite  other 
agencies  acting  as  custodians  of  the  systems. 

The  CM  policy  for  NAWCTSD  should  include  reference  to  the 
appropriate  sections  of  NAVAIRINST  4130. 1C,  contained  in 
Chapter  6,  in  order  to  implement  the  appropriate  change 
control  policy. 

In  implementing  this  policy  it  should  be  remembered  that 
AIR-100  has  the  authority  to  review  and  approve  OPR  CM  plans 
for  aviation  owned  CIs.  In  the  case  of  non-aviation  CIs,  the 
agency  owning  the  Cl  will  have  to  review  and  approve  CM  plans 
for  that  Cl . 

4.  OPRs  are  responsible  for  implementing  CCB  directed 
actions.  This  requirement  relates  to  the  NAVAIR  CCB  chaired 
by  AIR- 100  and  to  CCBs  chartered  by  and  thus  subordinate  to 
the  NAVAIR  CCB  as  in  the  case  of  OPRs.  Class  I  engineering 


67 


change  proposals  may  be  delegated  to  an  OPR  during  the  CE&D, 
DEMVAL,  and  EMD  phases.  The  operation  of  CCBs  is  well 
document-ed  in  NAVAIRINST  4130. 1C  and  requires  little  analysis. 
With  relation  to  implementing  policy  concerning  CCB  operation 
and  authority,  the  policy  for  NAWCTSD  can  be  clearly 
identified  by  referring  to  the  appropriate  section  in 
NAVAIRINST  4 130. 1C. 

5.  OPRs  are  responsible  for  maintaining  the  status  of 
implementing  actions  for  approved  engineering  changes, 
deviations,  and  waivers.  This  requirement  concerns 
documentation  of  actions  approved  or  disapproved  by  a  CCB. 
With  regard  to  overall  CM  policy,  NAVAIRINST  4130. 1C 
adequately  describes  the  process  by  which  this  requirement  is 
accomplished.  In  the  NAWCTSD  CM  policy,  this  can  be 
adequately  addressed  by  reference  to  the  appropriate  section 
in  NAVAIRINST  4 130. 1C. 

A  good  configuration  control  system  is  necessary  to 
reduce  program  risk.  Chapter  V  provided  the  necessary 
elements  of  a  comprehensive  configuration  control  system  from 
DoD  Directive  4245. 7-M.  For  purposes  of  configuration  control 
implementation  based  on  an  adequate  policy,  reference  should 
be  made  to  DoD  Directive  4245. 7-M  as  presented  in  Chapter  V. 

Because  of  NAWCTSD 's  extensive  involvement  with  other 
Government  agencies  and  with  the  surface  and  sub- surface 
communities  within  the  Navy,  the  requirement  for  maintaining 
the  status  of  implementing  actions  for  approved  engineering 
changes,  deviations,  and  waivers  is  significant  and  may  be 
more  difficult  to  manage  than  it  first  appears.  The  NAVAIR 
policy  assumes  that  the  Cl  is  under  NAVAIR  cognizance.  Since 
this  may  not  be  the  case  for  many  CIs,  under  the  cognizance  of 
NAWCTSD,  a  clarifying  statement  must  be  included  in  the  policy 
to  address  the  interface  between  NAWCTSD  and  other  agencies' 
CCBs.  The  same  procedural  methods,  or  process,  can  be  used 
for  maintaining  the  status  of  implementing  actions.  It  will 
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only  be  necessary  to  address  the  difference  in  the  interfaces, 
data  interfaces  and  organizational  interfaces,  between  the 
agencies-  to  facilitate  information  interchange. 

6.  OPRs  are  responsible  for  conducting  audits  and 
establishing  baselines.  The  policy  for  conducting  audits  and 
establishing  baselines  should  be  contained  in  a  CM  policy 
statement.  Since  Government  personnel  will  normally  perform 
audits,  CM  policy  should  so  state  that  fact  and  provide 
information  detailing  information  concerning  deviations  from 
the  policy.  Policy  should  also  identify  the  requirement  that 
audits  be  performed  over  the  life-cycle  of  a  Cl  including  how 
often  they  must  be  accomplished.  CM  policy  must  require 
appropriate  provisions  in  procurement  contracts  to  clarify 
Government  and  contractor  responsibilities  during  all  phases 
of  the  system's  life-cycle. 

Baseline  establishment  is  dependent  upon  proper 
configuration  identification.  MIL-HDBK-61  identified 
configuration  identification  as  the  most  important  element  of 
configuration  management  as  identified  in  Chapter  V  of  this 
thesis.  Proper  configuration  identification  is  the  key  to 
configuration  control.  Thus,  a  comprehensive  CM  policy  will 
assure  that  configuration  identification  is  clearly  given 
priority  treatment  in  the  development  of  CM  plans  and 
implemented  CM  systems . 

7 .  OPRs  are  responsible  for  establishing  and  maintaining 
an  adequate  configuration  status  accounting  system.  One  of 

the  problems  in  analyzing  this  requirement  is  in  determining 
what  is  meant  by  the  word  "adequate."  For  purposes  of  CM 
policy,  the  author  chooses  to  define  "adequate"  as  a  CSA 
system  that  satisfies  the  data  requirements  of  all  customers 
both  internal  and  external  to  NAWCTSD.  The  definition  of  CSA 
in  Appendix  C  is  more  specific  since  it  includes  the  elements 
necessary  to  record  and  report  information  needed  to  manage 
configuration  management  effectively.  The  policy  statement 
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need  only  reference  the  definition  of  CSA,  as  written  in 
Appendix  C,  to  assure  that  all  elements  of  CSA  are  identified 
as  required  in  the  resulting  system. 

Research  indicates  that  a  central  data  base  is  mandatory 
to  implement  this  requirement.  The  data  base  should  be  robust 
enough  to  satisfy  the  needs  of  all  users  and  customers  both 
internal  and  external  to  NAWCTSD.  It  should  also  be  designed 
to  be  accessible  to  both  Government  and  contractor 
organizations  in  order  to  assure  the  most  efficient  input  of 
data  and  availability  of  information  suited  to  the  specific 
needs  of  individual  programs . 

Data  specifications  for  a  central  data  base  should  be 
included  in  acquisition  and  internal  implementing  documents 
such  as  Statements  of  Work  (SOWs)  and  inserted  in  appropriate 
contracts  to  assure  data  commonality  among  the  many  CIs 
managed  by  NAWCTSD.  This  will  also  assure  that  the  system  is 
accessible  by  contractor  and  Government  agencies  as  needed  for 
review  and  input  of  data . 

For  purposes  of  CM  policy  it  is  necessary  to  include  a 
specific  definition  of  the  term  CSA  either  as  a  reference  or 
as  an  appendix  to  the  policy.  It  is  the  experience  of  the 
author  that  CSA  is  viewed  differently  by  every  level  of  the 
implementing  organizations.  Implementers  at  the  development 
or  modification  level  require  certain  information,  managers 
require  different  or  summary  information  and  so  on  up  the 
chain  of  command.  CM  policy  for  the  NAWCTSD  must  address  the 
different  levels  of  information  requirements  for  individual 
users  in  order  to  establish  a  policy  that  is  both  adequate  and 
effective  for  NAVAIR  as  well  as  other  users  and  for  those  at 
the  implementation  and  management  stages  and  all  users  in 
between . 

In  developing  and  analyzing  CM  policy  it  is  important  to 
remember  that  tailoring  is  a  cornerstone  of  present 
acquisition  policy.  Tailoring  of  CM  requirements  is  also 
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required  in  order  to  meet  the  requirements  of  multiple 
customers.  In  tailoring  requirements,  the  limitations  must  be 
understood  in  order  that  essential  or  statutory  requirements 
are  not  "tailored  out."  Authority  of  CCBs  and  other  elements 
of  CM  may  require  waivers  from  NAVAIR  AIR-100,  in  order  to 
change  them  to  suit  a  specific  program. 

NAVAIRINST  4130. 1C  should  be  read  and  thoroughly 
understood  by  all  personnel  and  competencies  required  to 
implement  CM  under  the  policy  developed  by  NAWCTSD.  If 
necessary,  classes  should  be  taught  to  enhance  general 
knowledge  of  CM  requirements  and  implementation  strategies. 

One  item  that  is  not  covered  in  the  CM  policy  established 
in  NAVAIRINST  4130. 1C  is  the  level  to  which  CM  is  to  be 
performed.  DoDI  5000.2  states  unequivocally  that 
configuration  items  will  be  traceable  to  the  work  breakdown 
structure  (WBS)  [Ref:  8,  part  9A,  par.  3.b,  subpar  (1),  p.  9- 
A-2]  .  No  level  is  indicated  in  DoDI  5000.2.  A  work  breakdown 
structure  is  required  for  acquisition  programs  which  are 
defined  in  DoDI  5000.2. 

Based  on  the  requirements  in  DoD  5000.2,  a  WBS  should  be 
used  to  provide  at  least  an  initial  system  description  for 
configuration  identification  purposes.  This  requirement 
belongs  in  a  comprehensive  CM  policy  providing  the  limitations 
of  work  breakdown  structures  are  known  as  described  in  Chapter 
V  of  this  thesis.  Furthermore,  as  a  matter  of  policy,  it 
would  be  counterproductive  to  require  that  the  level  be 
greater  than  level  three,  at  least  in  the  early  stages  of 
system  procurement.  Levels  beyond  level  three  are  developed 
by  the  contractor  (the  first  three  levels  are  called  a  WBS 
summary  level  and  are  developed  by  the  program  manager)  and 
may  or  may  not  be  suitable  to  use  for  a  decomposition  of  the 
system  for  configuration  identification  purposes.  The  use  of 
the  WBS  beyond  level  three  should  be  determined  by  the 
specific  requirements  of  individual  programs  and  by  available 
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resources . 

As  a  final  note  of  interest  in  this  section,  it  must  be 
remember-ed  that  the  Perry  Memorandum  [Ref.  1]  is  having  far 
reaching  effects  on  the  way  the  Government  acquires  and 
manages  systems.  CM  will  be  affected  as  the  Government 
emphasizes  the  use  of  NDI  and  COTS  and  as  acquisition 
streamlining  efforts  materialize.  NAVAIR  policy  will  reflect 
these  changes  as  appropriate  and  at  a  time  when  it  becomes 
necessary  to  address  them.  The  author  cannot  forecast  how  the 
changes  will  affect  CM  policy  in  the  long  run.  It  is  almost 
certain,  however,  that  CM  policy  as  it  is  written  today  will 
be  altered  to  accommodate  heavy  contractor  and  industry 
involvement  in  performing  CM  functions.  A  look  at  the 
following  section  will  indicate  what  is  already  happening  on 
at  least  one  other  Government  procurement  with  regard  to 
contractor  involvement  in  CM. 

C.  CM  POLICIES  FOR  SIMILAR  GOVERNMENT  ORGANIZATIONS  AND 
INDUSTRY  FIRMS 

1.  Army  Tactical  Missile  System  (ATACMS) .  This  program 
is  using  the  contractor  to  perform  CM  functions.  Government 
involvement  is  through  CCB  chairmanship  and  membership.  This 
arrangement  simplifies  the  resulting  CM  policy  as  is  reflected 
in  Appendix  F  which  contains  the  entire  contractor  CM 
requirements  in  approximately  one- fourth  of  a  page.  The 
requirements  are  in  the  form  of  functional  requirements  and 
thus  eliminate  military  standards  and  specifications.  This  is 
in  keeping  with  the  desires  of  the  Army  Acquisition  Executive. 

Analysis  of  the  CM  requirements  in  the  SOW  indicate  that 
the  ATACMS  program  is  simplifying  Government  responsibility  in 
the  area  of  CM  policy  and  management  of  the  CM  process.  The 
ATACMS  CM  manager  has  changed  the  approach  to  CM  as  practiced 
prior  to  the  advent  of  the  Perry  Memorandum  [Ref.  1]  and  in 
response  to  the  Army  Acquisition  Executive.  It  is  evident 
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that  the  requirements  for  CM,  from  a  policy  perspective,  are 
that  present  and  future  requirements  for  CM  on  the  ATACMS 
system  is  entirely  functionally  based,  contractor  operated 
with  Government  CCB  chairmanship,  greatly  simplified,  and 
requires  fewer  deliverables  than  would  previously  have  been 
required. 

2.  Loral  Corporation.  CM  policy  is  embedded  in  their  CM 
process.  The  emphasis  on  CM  is  that  their  process  is  itself 
under  CM.  CM  is  a  state  of  mind  and  is  prevalent  in 
everything  they  do  to  produce  the  software  vital  to  the 
Shuttle  system.  This  may  not.  be  applicable  directly  to 
NAWCTSD's  CM  policy  since  NAWCTSD's  policy  is  largely  governed 
by  higher  echelon  instructions.  The  information  concerning 
the  successful  implementation  of  policy  as  practiced  by  Loral 
is  excellent  for  study  of  future  CM  policy  and  for  a  level  of 
contractor  involvement  in  the  CM  process . 

3.  NASA.  Both  the  hardware  and  software  CM  systems  for 
the  Shuttle  system  rely  heavily  on  contractor  involvement  in 
the  process .  The  only  direct  Government  involvement  in 
performing  CM  is  in  determining  the  requirements  for  CM  in 
contractual  documents  and  in  chairing  and  performing  as 
members  of  CCBs .  NASA  also  requires  that  contractors  maintain 
appropriate  data  bases  to  facilitate  information  requirements 
for  both  NASA  and  the  contractor. 

Research  indicates  that  this  has  been  a  wholly  successful 
approach  to  CM.  The  Shuttle  system  is  one  of  the  most  complex 
systems  in  existence  today.  The  configuration  changes  with 
each  flight.  Configuration  management  is  critical  to  the 
success  of  the  system.  The  system  is  not  plagued  by 
incompatibilities  between  the  diverse  parts  of  the  hardware 
and  software  nor  is  it  plagued  by  incompatibilities  between 
contractor  delivered  material  or  software  as  indicated  by  the 
interviews  conducted.  This  is  an  indication  of  the  success  of 
CM  as  practiced  on  the  Shuttle  system. 
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NASA's  whole  systems  approach,  included  in  Appendix  E, 
is  a  radical  change  from  that  being  employed  currently.  The 
idea  of  -integrating  the  software  and  hardware  CM  process  is 
appealing.  First,  it  eliminates  the  idea  of  requiring  two 
types  of  CM  systems  or  processes  to  perform  the  same  type  of 
job.  As  stated  in  Chapter  V  of  this  thesis,  there  are  many 
similarities  in  the  requirements  for  performing  CM  on  hardware 
and  on  software.  The  NASA  whole  systems  approach  recognizes 
the  similarities  and  leverages  them  to  accomplish  CM  in  a 
simpler,  more  efficient,  and  ultimately  more  manageable  CM 
process.  The  Total  Quality  Leadership  adage  is  that  we  should 
concentrate  on  the  process,  not  the  product.  That  is  what 
NASA  has  accomplished  in  its  whole  systems  approach. 

Although  NASA's  approach  may  require  too  much  change  in 
the  present  NAVAIR  and  NAWCTSD  systems,  analysis  of  the 
approach  indicates  that  it  has  many  attractive  features  and 
could  be  a  subject  for  future  theses  on  this  topic. 

D.  SIGNIFICANT  PROBLEMS  AND  ISSUES  UNIQUE  TO  NAWCTSD 

Analysis  of  the  data  indicates  that  the  problems 
associated  with  implementing  CM  at  NAWCTSD  are  exacerbated  by 
the  diverse  customer  base,  a  huge  inventory  of  systems,  and  a 
complex  interface  between  NAWCTSD  competencies  and  between 
internal  and  external  customers.  The  following  paragraphs 
analyze  those  problems . 

1.  Organizational  Problems 

NAWCTSD  is  in  the  midst  of  a  major  change  in  its 
structure.  Under  NAVAIR  guidance,  the  entire  NAVAIR  team  has 
been  designated  as  a  Competency  Aligned  Organization  (CAO) . 
This  thesis  will  not  address  the  implementation  of  NAWCTSD  as 
a  CAO  in  any  detail,  it  is  simply  noted  that  this  change 
represents  a  major  change  in  the  "way  we  do  business"  and  thus 
complicates  the  process  of  implementing  CM  policy  both  as  it 
exists  and  with  any  modifications  that  may  result  from 
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information  and  recommendations  derived  from  this  thesis. 

In  addition  to  the  instability  introduced  by  changing  to 
a  CAO  the  accomplishment  of  configuration  management  is 
complex  and  involves  many  different  competencies  and 
individuals.  When  the  diverse  customer  base  is  factored  in  to 
the  already  complex  internal  interfaces  required  to  accomplish 
CM  it  is  evident  that  there  are  and  will  be  organizational 
problems.  Some  of  those  problems  were  evident  from  the 
interviews  conducted  at  NAWCTSD  as  indicated  in  Chapter  V  of 
this  thesis  and  some  are  the  result  of  analysis  of  present  and 
potential  future  problems. 

One  of  the  major  question  concerning  implementation  of  CM 
policy  is  determining  who  (which  competency)  is  responsible 
for  CM  at  NAWCTSD.  There  are  two  parts  to  this  question.  One 
part  is  who  is  responsible  for  managing  CM  and  the  other  is 
who  is  responsible  for  implementing  CM  at  the  working  level. 

Competency  1.3.2  is  responsible  for  policy  and  oversight 
as  well  as  CCB  chairmanship  and  CCB  charters .  All  other 
competencies  are  implementers  of  CM  policy.  A  clear  cut 
charter  for  every  competency  involved  in  implementing  CM  at 
the  working  level  must  be  included  in  any  CM  policy.  The 
charter  must  explicitly  identify  the  requirements  of  that 
competency  with  respect  to  CM  implementation.  Program  level 
requirements  such  as  a  central  data  base  must  be  addressed  and 
managed  by  Competency  1.3.2. 

Until  recently  project  management  may  have  viewed  CM 
primarily  from  an  acquisition  perspective,  not  from  a  life- 
cycle  perspective.  Project  management  is  now  responsible  for 
acquired  systems  from  the  concept  exploration  phase  till 
disposal.  This  change  requires  that  project  management  view 
the  CM  process  as  a  continuum  from  the  acquisition  phase  until 
system  disposal .  This  means  that  at  any  given  time  in  a 
program,  the  emphasis  on  CM  will  change  depending  upon  the 
phase  of  the  system's  life-cycle.  CM  plans  are  dynamic  and 


75 


should  be  updated  at  each  phase  and  thus  organizational 
requirements  should  be  updated  at  each  phase  to  accommodate 
the  life’-cycle  phase  of  the  system.  If  properly  addressed  in 
the  charter  for  every  competency,  with  respect  to  individual 
systems,  the  problem  of  who  is  responsible  for  CM 
implementation  at  the  working  level  should  be  ansv^ered.  As 
indicated  in  Chapter  V  of  this  thesis,  the  project  manager 
should  be  assisted  by  the  assigned  logistician  in  determining 
CM  requirements  for  individual  systems.  This  hopefully 
symbiotic  relationship  should  be  continued  throughout  the 
life-cycle  of  the  system. 

The  responsibility  of  some  competencies  such  as  In- 
Service  Engineering  Offices  (ISEOs)  or  logistics  competencies 
will  be  different  because  of  customer  interface  and  customer 
requirements.  Also,  ISEOs  actually  perform  engineering 
modifications  to  systems  as  well  as  support  system 
acquisition.  Most  competencies  will  have  complex  interfaces 
with  customers  including  both  internal  and  external  NAWCTSD 
customers.  An  overall  CM  plan  with  addenda  used  to  tailor  or 
modify  them  to  specific  programs  will  answer  the  question  of 
who  is  responsible  for  implementing  and  who  is  responsible  for 
managing  CM  at  NAWCTSD  based  on  which  competency  is 
responsible  during  a  particular  life-cycle  phase.  A  CM  plan 
is  required  by  NAVAIRINST  4130. 1C  and,  since  NAWCTSD  manages 
many  configuration  items,  a  master  plan  with  addenda  is  both 
authorized  by  the  instruction  and  as  far  as  this  author  is 
concerned  is  mandatory  for  implementation  of  a  comprehensive 
CM  policy. 

Analysis  of  data  indicates  that  involvement  by  upper 
level  management  is  necessary  for  any  CM  plan  or  process  to 
work.  CM  as  practiced  in  many  organizations  is  not  given  a 
high  priority  by  upper  level  management.  Following  is  a  quote 
concerning  the  involvement  of  upper  level  management  in  the 
commercial  sector  [Ref;  15,  par.  10.1.6,  p.  10-3] 
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Successful  major  systems  programs  in  the  commercial 
acquisition  environment  are  the  product  of 
unequivocal  top-management  approval  and  support. 

In -projects  reflecting  the  strategic  emphasis  of 
the  company,  there  is  clear  linkage  to 
organizational  business  strategy  and  a  direct 
involvement  of  the  CEO.  Involvement  does  not  mean 
micro-management,  but  it  does  mean  awareness  of  the 
project's  current  status,  an  active  questioning, 
and  willingness  to  commit  the  organization's 
resources  to  resolve  problems. 

This  commitment  by  upper  management  can  be  applied  to 
Government  as  well  as  commercial  organizations.  In  the  case 
of  NAWCTSD,  project  managers  must  be  committed  to  CM 
implementation  as  an  adjunct  to  their  management  tools  as  well 
as  a  life-cycle  cost  saving  strategy. 

Given  a  clear  cut  charter  for  all  competencies  involved 
in  managing  or  implementing  CM  at  NAWCTSD,  an  umbrella  CM  plan 
with  addenda,  and  commitment  by  upper  level  management  to  the 
tenets  of  CM,  the  question  of  who  is  responsible  for  CM  and 
who  will  implement  CM  will  be  answered  clearly.  This  will 
eliminate  many  of  the  organizational  problems  extant  at 
NAWCTSD . 

2 .  CM  Concept  Interpretations 

A  question  that  has  arisen  frequently  regarding  CM  policy 
concerns  the  level  to  which  CM  is  to  be  done.  It  is  important 
that  this  question  be  answered  as  a  matter  of  policy  because 
this  question  involves  the  distribution  of  scarce  resources. 
Analysis  indicates  that  as  a  matter  of  policy  there  can  be  no 
single  answer  to  this  question.  The  answer  to  the  question 
was  not  provided  by  analysis  of  data  in  this  thesis. 
Deductive  reasoning  provides  a  partial  answer  which  may  be 
made  a  matter  of  policy. 

Department  of  Defense  Instruction  5000.2  requires  that 
configuration  items  be  directly  traceable  to  the  work 
breakdown  structure.  Although  the  level  of  CM  is  not 
specified  it  is  evident  that  the  level  is  dependent  upon  the 
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system's  life-cycle  phase.  As  a  minimum,  however,  the  summary 
WBS  level  should  provide  a  good  starting  point  for  identifying 
the  leve-1  of  CM  to  be  performed.  Beyond  that  level,  which  is 
three  levels  deep,  specific  program  requirements  will 
determine  the  level  to  which  CM  is  to  be  performed.  Usually, 
this  will  be  determined  by  the  amount  of  resources  available 
in  a  given  program  to  support  the  decomposition  of  the  system 
into  elements  that  are  sufficiently  detailed  to  adequately 
describe  the  system  and  to  facilitate  CM. 

The  level  may  be  different  based  solely  on  customer 
requirements.  Once  again,  customer  requirements  will,  most 
likely  be  based  on  available  resources.  The  difference 
between  resources  required  and  resources  available  for  CM  will 
be  no  different  in  the  determination  of  the  CM  system  adapted 
than  to  any  other  element  of  acquisition  or  life- cycle 
support . 

CM  over  the  life-cycle  of  systems  was  identified  in 
interviews  as  a  problem  for  all  systems .  Inherent  in  the 
problem  are  the  problems  identified  and  analyzed  in  sub¬ 
sections  one  through  three  of  this  section.  The  problem  of  CM 
over  the  life-cycle  involves  who  is  going  to  perform  CM,  who 
will  be  in  charge  or  manage  CM,  who  will  provide  resources  at 
a  given  phase  of  the  life-cycle  and  what  is  required  by 
instructions  or  regulations  depending  upon  the  life- cycle 
phase  of  the  system. 

The  research  indicated  simply  that  CM  is  required  for  the 
entire  life-cycle  of  the  system.  The  type  of  CM  performed 
during  the  acquisition  stage  is  done  by  the  development  or 
production  contractor  with  Government  chairmanship  of  CCBs  or 
at  least  attendance  as  a  voting  member  on  a  given  CCB .  Policy 
should,  however,  clearly  identify  both  contractor  and 
Government  involvement  and  responsibilities  in  the  process. 
This  can  be  done  by  properly  maintaining  the  addenda  to  the 
master  CM  plan  as  the  system  progresses  through  the  various 
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phases  from  acquisition  to  operation  and  support. 

As  the  system  is  made  operable,  in  some  cases  the 
Government  (in  the  case  of  NAWCTSD  an  ISEO)  will  perform  CM 
exclusively,  or  both  the  Government  and  a  support  contractor 
will  perform  CM,  or  a  support  contractor  will  perform  CM 
exclusively  for  the  Government.  In  all  of  these  cases  a 
master  CM  plan  with  addenda  modified  and  updated  at  each  phase 
of  the  life-cycle  will  clarify  participating  roles  and 
responsibilities . 

NAWCTSD  sometimes  acquires  a  system  for  support  after  it 
was  procured  by  another  agency.  In  these  cases  CM  for  the 
system  may  have  been  addressed  or  it  may  accrue  to  NAWCTSD  to 
develop  the  system.  Depending  on  the  resources  available,  the 
addenda  to  the  master  plan  would  accommodate  starting  a  CM 
system  or  assuming  responsibility  for  maintaining  a  CM  system 
status-quo  if  it  existed.  CM  policy  must  address  all 
possibilities  of  required  CM  support  as  a  matter  of  policy  in 
order  to  clarify  roles  and  responsibilities  for  all 
individuals  within  competencies. 

3 .  Conflicting  Regulations  and  Directives 

This  problem  is  addressed  by  determining  what  is  required 
and  what  is  recommended.  Instructions  are,  by  definition,  not 
directives  and  are  thus  open  to  interpretation  and  some  leeway 
in  implementation.  However,  superior  instructions  carry  the 
weight  of  authority  of  the  superior  organization  and  thus  in 
most  cases  implementing  organizations  attempt  to  follow 
instructions  as  closely  as  possible. 

In  the  case  of  NAWCTSD,  the  superior  organization  and 
instruction  is  NAVAIR  and  NAVAIRINST  4130. 1C  respectively. 
Measured  against  NAVAIRINST  4130. 1C  there  are  few  if  any 
conflicts  with  DoD  instructions  and  regulations  and  none  with 
existing  regulations  at  NAWCTSD.  The  author  was  unable  to 
find  any  statutory  requirements  with  regard  to  CM.  Therefore, 
it  is  the  author's  opinion  that  the  instructions  implementing 
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both  policy  and  CM  at  the  working  level  from  the  Secretary  of 
the  Navy  to  NAWCTSD  are  not  in  conflict. 

Chapter  V  identified  the  fact  that  NAVAIRINST  4130. 1C  did 
not  indicate  the  level  to  which  CM  was  to  be  performed.  DoD 
5000.2  requires  only  that  configuration  items  be  traceable  to 
a  work  breakdown  structure.  This  is  not  a  conflict  since  DoD 
Instruction  5000.2  can  be  tailored  to  individual  programs  and 
projects.  NAVAIRINST  4130. 1C  does  not  address  every  issue 
faced  by  NAWCTSD  in  implementing  CM  across  all  platforms  and 
systems  supported  by  NAWCTSD.  This  is  not  a  conflict,  it 
simply  requires  that  NAWCTSD  "fill  in  the  blanks"  in  order  to 
develop  a  comprehensive  CM  policy  and  implementation  plan.  In 
essence,  latitude  is  allowed  in  order  for  subordinate  entities 
to  fulfill  requirements  that  may  not  be  known  to  superiors. 
This  does  not  give  NAWCTSD  free  reign  to  develop  policy 
outside  the  legal  purview  of  the  DoD  but  it  does  give  ample 
room  to  develop  policy  that  will  be  successful  in 
accomplishing  the  requirement  to  implement  CM  as  an  Office  of 
Primary  Responsibility  (OPR)  under  NAVAIR. 

The  greatest  single  potential  conflicting  in  interpreting 
and  implementing  CM  is  the  interpretation  and  implementation 
of  the  Perry  Memorandum  [Ref.  1] .  No  other  single  document 
has  such  far  reaching  potential  to  cause  change  in  the 
acquisition,  and  by  default,  the  life-cycle  support  of  DoD 
systems.  For  purposes  of  analysis  by  the  author,  it  is  only 
clear  that  change  is  inevitable.  The  resulting  change  will 
affect  every  aspect  of  system  procurement  and  life-cycle 
support.  Exactly  how  it  will  affect  it  and  the  time-table  are 
unknown . 


80 


VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

NAWCTSD  confronts  a  monumental  task  in  responding  to  CM 
requirements  across  the  broad  spectrum  of  Services,  other 
Government  agencies,  non -Government  agencies,  and  a  huge  and 
diverse  inventory  of  training  devices  and  systems.  It  is 
clear  that  CM  efforts  at  NAWCTSD  can  benefit  by  improving  and 
clarifying  policy  and  implementation  requirements.  NAWCTSD 
can  also  benefit  by  improving  the  management  of  its  CM  effort 
to  address  the  differences  as  well  as  the  common  elements  of 
CM  across  the  spectrum  of  systems  supported  by  NAWCTSD.  Both 
internal  and  external  customers  will  benefit  if  improvements 
are  made  in  policy  and  policy  implementation. 

The  instruction  governing  the  implementation  of  CM  at 
NAWCTSD,  NAVAIRINST  4130. 1C,  is  comprehensive  and  empowers 
NAWCTSD  to  accomplish  its  CM  responsibilities  in  the  most 
efficient  manner  possible.  As  an  OPR,  NAWCTSD  is  given  clear 
directions  contained  in  the  list  of  OPR  responsibilities. 
Those  responsibilities  are  the  minimum  required  and  thus 
NAWCTSD  may  add  to  them  as  needed  in  order  to  accomplish  or 
enhance  the  accomplishment  of  its  CM  mission.  This  thesis 
will  recommend  additional  elements  of  CM  that  should  be  added 
to  the  list  of  requirements  and  will  also  suggest  other 
changes  to  the  present  system  to  enhance  its  effectiveness. 

B .  RECOMMENDAT I ONS 

To  effectively  implement  CM  policy  at  NAWCTSD  it  is 
necessary  that  upper  level  management  commit  adequate 
resources  to  accomplish  and  demonstrate  support  of  CM  policy. 
Competency  1.3.2  in  its  role  of  CM  management  at  NAWCTSD  must 
effectively  communicate  policy  to  all  competencies  tasked  with 
implementing  that  policy.  This  thesis  identifies  essential 
elements  of  CM  policy  and  addresses  issues  relevant  to 
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implementing  that  policy.  The  thesis  did  not  provide  a 
written  policy.  Competency  1.3.2  should  modify  the  existing 
policy  based  on  recommendations  from  this  thesis.  The 
resulting  written  policy  should  be  concise,  easy  to  read  and 
easy  to  understand.  It  should  reference  NAVAIRINST  4130. 1C  as 
the  primary  superior  instruction  and,  where  appropriate  for 
clarity,  it  should  reference  exact  paragraphs  or  sections  in 
that  instruction  in  order  to  enhance  clarity  of  requirements. 
It  should  also  reference  other  DoD  instructions  and  military 
standards  as  needed  and  identified  in  the  answers  to  the 
research  subsidiary  questions. 

The  policy  should  identify  core  CM  tasks  to  be 
accomplished  by  NAWCTSD  competencies.  The  accomplishment  of 
core  CM  tasks  should  be  standardized  with  respect  to  data 
requirements  and  procedures.  At  the  same  time,  the  policy 
must  address  the  CM  requirements  for  individual  programs.  It 
must  identify  potential  differences  in  implementation  of  CM 
across  the  spectrum  of  supported  devices  and  customers  and 
must  also  account  for  the  implementation  of  CM  by  ISEOs 
actually  performing  engineering  modification  tasks  or 
supporting  acquisition  programs. 

The  roles  and  responsibilities  of  every  competency  tasked 
to  perform  CM  for  NAWCTSD  acquired  and  supported  devices  must 
be  clearly  established  in  written  policy.  Additionally, 
Competency  1.3.2  should  address  updating  CCB  charters  for 
NAWCTSD  acquired  and  supported  devices  to  clarify  the  role  of 
NAWCTSD  versus  that  of  NAVAIR  in  maintaining  CCB  control  of 
baselines.  In  order  to  facilitate  the  diverse  customer  and 
device  base,  it  is  recommended  that  Competency  1.3.2  write  a 
master  configuration  management  plan.  The  policy  statement 
should  describe  how  the  master  CM  plan  can  be  modified  by 
adding  addenda  to  the  plan  as  indicated  in  NAVAIRINST  4130. 1C. 
The  addenda  can  be  used  to  tailor  the  master  CM  plan  to 
accommodate  differences  in  individual  programs. 
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As  chair  of  the  TECCB  and  as  an  Associate  Member  of  the 
NAVAIR  CCB,  Competency  1.3.2  has  the  responsibility  to  assure 
that  all-  changes  to  existing  baselines  under  the  control  of 
NAWCTSD  are  properly  documented  and  traceable.  Establishment 
of  a  comprehensive  status  accounting  system  that  meets  the 
needs  of  all  users  and  customers,  internal  and  external  to 
NAWCTSD,  must  be  developed.  It  is  recommended  that  Competency 
1.3.2  use  the  expertise  of  personnel  in  the  Logistics  Support 
Competency  3.0  to  assist  in  developing  CM  policy,  implementing 
CM  policy,  and  providing  life-cycle  support  for  CM.  This 
recommendation  is  based  on  the  fact  that  Competency  3.0  was 
the  lead  competency  until  approximately  November  1994. 
Competency  3 . 0  also  has  the  lead  on  the  development  of  the 
configuration  status  accounting  data  base. 

It  is  recommended  that  the  frequency  of  audits  and  the 
competencies  responsible  for  performing  audits  be  included  in 
the  written  CM  policy  statement. 

The  final  recommendation  relative  to  implementing  CM 
policy  at  NAWCTSD  concerns  training  of  key  personnel.  CM  is 
a  complex  endeavor.  It  requires  knowledge  of  CM  processes  and 
procedures  as  well  as  goals  and  limitations .  The  theoretical 
knowledge  is  contained  in  text  books  and  articles,  some  of 
which  are  referenced  and  discussed  in  this  thesis.  The 
working  and  implementation  knowledge  is  contained  in  technical 
manuals,  instructions,  and  military  standards  and 
specifications.  Personnel  required  to  implement  and  manage  CM 
must  be  trained  in  order  to  perform  the  necessary  functions. 
It  is  recommended  that  Competency  1.3.2  establish  a  CM 
training  plan  and  that  specific  personnel  be  targeted  to 
receive  CM  training  as  needed. 
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C.  ANSWERS  TO  RESEARCH  AND  SUBSIDIARY  QUESTIONS 

1.  Research  Question 

What  should  be  the  essential  elements  of  a  Configuration 
Management  (CM)  policy  for  NAWCTSD  acquisitions  and  how  might 
this  policy  be  implemented? 

FOUR  MAJOR  ELEMENTS  OF  CM: 

The  question  of  how  the  policy  might  be  implemented  is 
answered  in  the  subsidiary  questions. 

1.  Configuration  Identification.  Selection  of  the 
documents  which  identify  and  define  the  configuration 
baseline  characteristics  of  an  item. 

2.  Configuration  Control.  Controlling  changes  to  the 
configuration  and  its  identification  documents. 

3.  Configuration  Status  Accounting.  Recording  and 
reporting  the  implementation  of  changes  to  the 
configuration  and  its  identification  documents. 

4.  Configuration  Audit.  Checking  an  item  for 
compliance  with  the  configuration  identification. 


2 .  S\ibsidiary  Questions 

What  are  the  essential  elements  of  CM  policy  and  what  are 
the  requirements  established  by  DoN,  DoD,  and  other  Government 
agencies? 

The  following  answers  are  summary  answers.  Detailed 
answers  are  available  in  previous  chapters . 

Essential  elements  include  CM  plans,  configuration 
identification,  change  control,  configuration  status 
accounting,  technical  documentation  management,  physical  and 
functional  audits,  and  that  CM  be  performed  for  the  life-cycle 
of  a  configuration  item. 

NAVAIRINST  4130. 1C  requires  the  following  seven  CM 
functions  (discussed  in  detail  in  the  body  of  the  thesis)  of 
NAWCTSD  because  NAWCTSD  is  an  Office  of  Primary  Responsibility 
(OPR)  : 
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1.  provide  CM  of  assigned  CIs  throughout  their  life 
cycle ; 

2.  -  prepare  and  maintain  CM  plans  for  assigned  Cis; 
obtaining  approval  of  these  plans,  and  assuring  proper 
implementation  of  NAVAIRINST  4130. 1C; 

3.  manage  and  provide  direction  for  the  staffing  of  all 
engineering  change  proposals,  RAMECs,  and  requests  for 
major  and  critical  deviations  and  waivers  from  initiation 
until  submittal  to  a  CCB; 

4.  implement  CCB  directed  actions; 

5 .  maintain  the  status  of  implementing  actions  for 
approved  engineering  changes,  deviations,  and  waivers; 

6.  conduct  audits,  establish  baselines;  and 

7.  establish  and  maintain  an  adequate  configuration 
status  accounting  system. 

NAVAIRINST  4130. 1C  requires  that  NAWCTSD  develop  a  CM 
master  plan  since  it  is  responsible  for  more  than  one 
configuration  item.  The  master  plan  can  be  tailored  to  suite 
specific  programs  (configuration  items)  by  the  addition  of 
addenda  to  the  master  plan. 

DoDI  5000.2  states  that  all  configuration  items  be 
traceable  to  an  element  of  a  work  breakdown  structure. 
NAVAIRINST  4130. 1C  does  not  mention  this  requirement.  It  is 
the  recommendation  of  this  thesis  that  this  be  established  as 
a  matter  of  policy.  Other  details  of  requirements  from  DoDI 
5000.2  are  included  in  the  body  of  the  thesis. 

What  are  the  basic  components  of  CM  policies  that  exist 
for  similar  Government  organizations  and  industry  firms? 

Research  failed  to  identify  other  Government  agencies 
that  paralleled  NAWCTSD  in  function.  Other  agencies  do  not 
have  the  same  large  customer  base,  nor  are  they  responsible 
for  such  a  large  and  diverse  number  of  complex  configuration 
items .  NAWCTSD  appears  to  be  unique  in  that  respect .  Other 
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agencies  were  studied,  however,  to  determine  their  approach  to 
implementing  CM  and  their  policy. 

The  Army  Tactical  Missile  System  (ATACMS)  uses  the 
contractor  to  perform  CM  on  developing  and  delivered  systems. 
Army  involvement  is  to  chair  the  CCB  and  to  be  a  member  of 
CCBs  as  necessary  to  assure  Government  control  of  changes. 
Contractual  documents  reflect  the  Army  Acquisition  Executives 
policy  that  functional  specifications  and  simplified 
statements  of  work  be  implemented  in  order  to  streamline  the 
process  and  reduce  cost. 

NASA  uses  contractors  exclusively  to  perform  CM  for 
hardware  and  software.  Their  involvement  is  the  same  as  the 
Airmy.  They  chair  the  CCBs  or  are  members  of  CCBs  for  every 
element  of  the  shuttle  program. 

Loral,  under  contract  to  NASA  for  Shuttle  software 
development  has  achieved  a  high  level  of  process  maturity.  CM 
is  a  part  of  every  process  at  Loral .  The  process  of  CM  itself 
is  under  CM.  It  is  a  mind  set,  automatically  part  of  all 
processes,  at  every  level  of  the  company. 

What  are  the  significant  problems  and  issues  associated 
with  establishing  a  CM  policy  that  is  unique  to  NAWCTSD  and 
how  might  these  problems  and  issues  be  solved? 

It  is  important  to  determine  exactly  which  competency  is 
"in  charge"  of  CM  and  which  competencies  are  required  to 
implement  CM  on  their  programs  and  systems.  Competency  1.3.2 
is  tasked  with  developing  and  managing  CM  policy  at  NAWCTSD. 
Many  other  competencies  are  responsible  for  implementing 
policy.  The  policy  developed  for  NAWCTSD  should  require  that 
a  master  CM  plan  be  written  and  that  implementing  competencies 
modify  that  plan  with  attached  addenda  to  make  the  plan 
specific  to  their  needs  and  to  the  needs  of  their  customers. 

Problems  with  implementation  are  the  large  customer  base, 
the  large  size  of  the  inventory,  and  the  complex 
infrastructure  represented  by  the  various  competencies .  The 
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CM  policy  must  address  these  issues  by  clarifying  the  roles 
and  responsibilities  of  competencies  required  to  implement  CM. 
Acquisition  documents  must  reflect  CM  requirements  and  provide 
data  requirements  to  complement  the  NAWCTSD  status  accounting 
system. 

Training  must  be  developed  for  all  personnel  required  to 
implement  CM  in  order  to  assure  that  personnel  are  technically 
competent  and  to  improve  standardization  of  methodology. 

The  level  to  which  CM  is  to  be  implemented  is  answered  by 
the  requirement  contained  in  DoDI  5000.2  that  configuration 
items  be  traceable  to  the  work  breakdown  structure.  It  is  the 
recommendation  of  this  author  that  CM  be  performed  to  at  least 
level  three  (the  summary  level  WBS) .  Further  system 
decomposition  is  dependent  upon  individual  system  and  program 
requirements  and  resources. 

CM  during  the  acquisition  phase  begins  at  the  end  of 
concept  exploration  and  definition.  It  is  to  be  practiced  on 
a  continuum  during  all  life-cycle  phases  of  the  system.  CM 
plans  are  to  be  modified  and  updated  at  all  major  system 
milestones.  CM  on  fielded  systems  should  simply  be  a 
continuum  of  CM  planning  from  the  acquisition  phases.  If  not, 
CM  policy  must  dictate  that  necessary  CM  be  performed  in 
accordance  with  NAVAIRINST  4130. 1C  based  on  available 
resources  and  specific  system  requirements.  For  system 
acquired  by  other  agencies  and  turned  over  to  NAWCTSD  for 
support  under  the  Cognizance  Symbol  2"0"  umbrella,  CM  must  be 
practiced  the  same  as  for  all  other  systems  within  given 
resource  constraints. 

This  thesis  found  no  major  conflicts  between  DoD,  DoN, 
NAVAIR,  and  NAWCTSD  instructions.  Interpretation  of  those 
instructions  is  and  likely  always  will  be  contentious. 
Recognition  of  NAVAIRINST  4130. 1C  as  the  instruction  to  be 
used  to  implement  CM  and  CM  policy  at  NAWCTSD  will  assure  that 
there  is  no  conflict.  NAVAIRINST  4130. 1C  includes  minimum 
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instructions  and  therefore  additional  elements  can  be  added  to 
the  policy  to  enhance  that  required  by  NAVAIR. 

The  advent  of  the  Perry  Memorandum  [Ref.  1]  has  caused  a 
great  deal  of  flux  in  the  implementation  of  military  standards 
and  specifications.  The  whole  of  acquisition  is  changing  to 
streamline  the  process.  CM  is  part  of  the  impacted  processes. 
MlL-STD-973  was  to  be  the  answer  to  standardizing  CM  and  CM 
processes.  The  Perry  Memorandum  [Ref.  1]  will  likely  affect 
implementation  of  MIL-STD-973  in  a  negative  way. 

D.  AREAS  FOR  FURTHER  RESEARCH 

The  NASA  whole  systems  approach  to  CM  is  worthy  of 
additional  study.  NASA's  Ames  Research  Center  has  implemented 
a  CM  system  that  employs  virtually  the  same  process  on  both 
hardware  and  software  CM. 
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APPENDIX  A 


DENDRITIC  ANALYSIS 


Dendritic  Approach  to  Determining  Essential  Elements  of  CM  Policy  for  NAWCTSD 
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APPENDIX  B 


GLOSSARY  OF  ACRONYMS 


AAE 
ACAT  I 
AC  I 

ATACMS 

ATE 

CALS 

CASE 

CCB 

CDRL 

CE&D 

Cl 

CM 

CMIS 

CSA 

DEMVAL 

DoD 

DoDI 

Don 

DPRO 

ECP 

EMD 

FCI 

HCM 

I  CD 

ICWG 

IEEE 

ILSM 

IRN 


Army  Acquisition  Executive 
Acquisition  Category  1 

Allocated  Configuration  Identification 
Airniy  Tactical  Missile  System 
Automatic  Test  Equipment 

Computer-aided  Acquisition  and  Logistics  Support 

Computer  Aided  Software  Engineering 

Change  Control  Board 

Contract  Deliverable 

Concept  Exploration  and  Definition 

Configuration  Item 

Configuration  Management 

Configuration  Management  Information  System 

Configuration  Status  Accounting 

Demonstration  and  Validation 

Department  of  Defense 

Department  of  Defense  Instruction 

Department  of  the  Navy 

Defense  Plant  Representative  Office 

Engineering  Change  Proposal 

Engineering  and  Manufacturing  Development 

Functional  Configuration  Identification 

Hardware  Configuration  Management 

Interface  Control  Drawing 

Interface  Control  Working  Group 

International  Electical  and  Electronics  Engineering 
Integrated  Logistics  Support  Manager 
Interface  Revision  Notice 
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ISEO 

LCS 

MOA 

MOE 

MOP 

NASA 

NAWCTSD 

NDI 

NOR 

NPS 

NSTS 

PCI 

PO&M 

0&M,N 

OPR 

PCA 

PD 

PJM 

PM 

RAMEC 

RFP 

SCM 

SCN 

SCCB 

SOW 

SSP 

STE 

SWFPAC 

TECCB 

TECP 

WBS 


In-Service  Engineering  Office  (ISEO) 

Life  Cycle  Support 
Memorandum  of  Agreement 
Measure  of  Effectiveness 
Measure  of  Performance 

National  Aeronautics  and  Space  Administration 

Naval  Air  Warfare  Center  Training  Systems  Division 

Nondevelopmental  Item 

Notice  of  Revision 

Naval  Postgraduate  School 

National  Space  Transportation  System 

Physical  Configuration  Item 

Operation  and  Maintenance 

Operation  and  Maintenance,  Navy 

Office  of  Primary  Responsibility 

Physical  Configuration  Audit 

Project  Director 

Project  Manager 

Project  Manager 

Rapid  Action  Minor  Engineering  Change 

Request  for  Proposal 

Software  Configuration  Management 

Software  Change  Notice 

Software  Change  Control  Board 

Statement  of  Work 

Space  Shuttle  Program 

Software  Test  Equipment 

Surface  Warfare  Pacific 

Trainer  Engineering  Change  Control  Board 
Trainer  Engineering  Change  Proposal 
Work  Breakdown  Structure 
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APPENDIX  C 


DEFINITION  OF  TERMS 

1.  ALLOCATED  BASELINE.  The  initially  approved 
documentation  describing  an  item' s  functional  and  interface 
characterisitics  that  are  allocated  from  those  of  a  higher- 
level  configuration  item,  interface  requirements  with 
interfacing  configuration  items,  additional  design 
constraints,  and  the  verification  required  to  demonstrate  the 
achievement  of  those  specified  functional  and  interface 
characteristics . 

2.  BASELINE.  A  configuration  identification  document  or 
a  set  of  documents  formally  designated  and  fixed  at  a  specific 
time  during  a  configuration  item's  (Cl's)  life  cycle. 
Baselines  plus  approved  changes  from  those  baselines, 
constitute  the  current  configuration  identification. 

3.  Cognizant  Field  Activity  (CFA)  .  The  Navy  field 
activity  which  has  been  assigned  the  responsibility  and 
delegated  the  authority  by  NAVAIRSYSCOM  HQ  under  reference  (q) 
to  perform  all  or  portions  of  the  in-service  functions, 
including  procurement  support,  for  specific  service  equipment. 

4.  Cognizance  Symbol  2"0''  Equipment.  Those  training 
device  end  items  that  have  been  specifically  developed, 
procured,  cataloged,  distributed,  and  supported  by 
NAVAIRWARCENTRASYSDIV  to  fulfill  a  training  requirement.  It 
also  includes  training  devices  procured  outside  of  the  NAWCTSD 
and  subsequently  transferred  by  mutual  agreement  to  NAWCTSD 
for  inventory  management,  maintenance,  and  support. 

5.  Configuration .  The  functional  and  physical 
characteristics  of  existing  or  planned  hardware,  firmware, 
software,  or  a  combination  thereof  as  set  forth  in  technical 
documentation  and  ultimately  achieved  in  a  product. 
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6-  Configuration  Baseline  .  Configuration  documentation 
fomally  designated  by  the  Government  at  a  specific  time 
during  -a  configuration  item's  (Cl's)  life  cycle. 
Configuration  baselines,  plus  approved  changes  from  those 
baselines,  constitute  the  current  approved  configuration 
documentation.  There  are  three  formally  designated 
configuration  baselines  in  the  life  cycle  of  a  configuration 
item,  namely  the  functional,  allocated,  and  product  baselines. 

7.  Configuration  Control.  The  systematic  proposal, 
justification,  evaluation,  coordination,  approval  or 
disapproval  of  proposed  changes,  and  the  implementation  of  all 
approved  changes  in  the  configuration  of  a  Cl  after 
establishment  of  the  configuration  baseline (s)  for  the  Cl. 

8.  Configuration  Control  Board  (CCB) .  A  board  composed 
of  technical  and  administrative  representatives  who  recommend 
approval  or  disapproval  of  proposed  engineering  changes  to  a 
Cl's  current  approved  configuration  documentation.  The  board 
also  recommends  approval  or  disapproval  of  proposed  waivers 
and  deviations  from  a  Cl's  current  approved  configuration 
documentation . 

9-  Configuration  Identification.  Configuration 
identification  includes  the  selection  of  CIs;  the 
determination  of  the  types  of  configuration  documentation 
required  for  each  Cl;  the  issuance  of  numbers  and  other 
identifiers  affixed  to  the  CIs  and  to  the  technical 
documentation  that  defines  the  Cl's  configuration,  including 
internal  and  external  interfaces,-  the  release  of  CIs  and  their 
associated  configuration  documentation,-  and  the  establishment 
of  configuration  baselines  for  CIs. 

10-  Configuration  Item  (Cl)  .  A  configuration  item  is  an 
aggregation  of  hardware  or  software  that  satisfies  an  end  use 
function,  and  is  designated  by  the  Government  for  separate 
configuration  management. 

11 .  Configuration  Management  (CM) . 
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a.  As  Applied  to  configuration  items  a  discipline 
applying  technical  and  administrative  direction  and 
surveillance  over  the  life- cycle  of  items  to; 

(1)  Identify  and  document  the  functional  and 
physical  characteristics  of  configuration  items. 

(2)  Control  changes  to  configuration  items  and 
their  related  documentation. 

(3)  Record  and  report  information  needed  to 
manage  configuration  items  effectively,  including  the  status 
of  proposed  changes  and  implementation  status  of  approved 
changes . 

(4)  Audit  configuration  items  to  verify 
conformance  to  specifications,  drawings,  interface  control 
documents,  and  other  tasking  or  contract  requirements. 

b.  As  applied  to  digital  data  files  the 
application  of  selected  configuration  identification  and 
configuration  status  accounting  principles  to: 

(1)  Uniquely  identify  the  digital  data  files 
including  versions  of  the  files  and  their  status  (e.g. 
working,  released,  submitted,  approved) . 

(2)  Record  and  report  information  needed  to 
manage  the  data  files  effectively,  including  the  status  of 
updated  versions  of  files. 

12.  Conf icruration  Management  Support  System  (CMSS)  .  A 
NAWCTSD  remote  access  computerized  data  file  and  processor 
utilized  for  configuration  status  accounting  of  changes  to  COG 
2"0"  training  devices/systems. 

13.  Conf  icruration  Status  Accounting  (CSA)  .  The 
recording  and  reporting  of  information  needed  to  manage 
configuration  effectively,  including: 

a.  A  record  of  the  approved  configuration  documentation 
and  identification  numbers. 

b.  The  status  of  proposed  changes,  deviations,  and 
waivers  to  the  configuration. 
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c.  The  implementation  status  of  approved  changes. 

d.  The  configuration  of  all  units  of  the  configuration 
item  in  'the  operational  inventory. 

14.  Data ■  Recorded  information,  regardless  of  medium  or 
characteristics,  of  any  nature,  including  administrative, 
managerial,  financial,  and  technical. 

15.  Design  Change.  See  "engineering  change". 

16 .  Digital  Technical  Data.  A  primary  thrust  of  the 
Computer-Aided  Acquisition  and  Logistics  Support  (CALS)  effort 
is  the  automation  and  integration  of  the  generation,  delivery, 
and  use  of  weapon  system  technical  data  over  the  weapon 
system's  life  cycle.  This  technical  data  includes: 

a.  The  part  descriptions,  product  specifications, 
and  standards  that  the  initial  designer  draws  upon. 

b.  The  engineering  drawings  and  product  data  used 
in  design  and  manufacturing,  including  product  descriptions 
and  specifications  data  used  for  design  reviews. 

c.  The  information  needed  to  guide  the  people  who 
operate  the  system  in  the  field,  or  who  support  and  maintain 
it  at  all  echelons  of  the  logistic  support  structure. 

d.  The  materials  needed  to  train  new  operators, 
maintainers  and  other  technicians,  and  the  information  needed 
for  re -procurement ,  remanufacturing,  modification,  and 
feedback  to  industry  for  future  design. 

(CALS  has  published  technical  standards  which  enable  either 
delivery  of  this  info2rmation  in  digital  form  or  government 
access  to  contractor-maintained  technical  data  bases.) 

17.  Engineering  Change .  A  change  to  the  current 
approved  configuration  documentation  of  a  configuration  item 
at  any  point  in  the  life  cycle  of  the  item. 

18.  Engineering  Change  Priorities.  The  priority 
(emergency,  urgent,  routine)  assigned  to  a  Class  I  engineering 
change  which  determines  the  relative  speed  at  which  the 
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Engineering  Change  Proposal  is  to  be  reviewed,  evaluated, 
and, if  approved,  ordered  and  implemented. 

19  .-  Engineering  Change  Proposal  (ECP)  .  A  proposed 
engineering  change  and  the  documentation  by  which  the  change 
is  described,  justified,  and  submitted  to  the  Government  for 
approval  or  disapproval . 

20.  Engineering  Change  Proposal  Types .  A  term  covering 
the  subdivision  of  Class  I  Engineering  Change  Proposals  on  the 
basis  of  the  completeness  of  the  available  information 
delineating  and  defining  the  engineering  change.  They  will  be 
identified  as  preliminary  or  formal. 

21.  Functional  Baseline  (FBL) .  The  initially  approved 
documentation  describing  a  system's  or  item's  functional, 
interoperability,  and  interface  characteristics  and  the 
verification  required  to  demonstrate  the  achievement  of  those 
specified  characteristics. 

22.  Functional  Characteristics.  Quantitative 
performance  parameters  and  design  constraints,  including 
operational  and  logistic  parameters  and  their  respective 
tolerances.  Functional  characteristics  include  all 
performance  parameters,  such  as  range,  speed,  lethality, 
reliability,  maintainability,  and  safety. 

23.  Functional  Configuration  Audit  (FCA) .  The  formal 
examination  of  functional  characteristics  of  a  configuration 
item,  prior  to  acceptance,  to  verify  that  the  item  has 
achieved  the  requirements  specified  in  its  functional  and 
allocated  configuration  documentation. 

24 .  Government  Furnished  Equipment  (GFE) /Government 
Furnished  Property  (GFP) .  Property  in  the  possession  or 
acquired  by  the  Government  and  subsequently  delivered  or 
otherwise  made  available  to  the  contractor. 

25.  In-Service  Engineer  Office _ ( ISEO)  .  A 

NAVAIRWARCENTRASYSDIV  field  office  staffed  with  specialists 
who  provide  Cognizance  Symbol  2"0"  training  device/system 


101 


technical,  engineering,  and  logistics  support  through  direct 
responses  to  equipment  users/custodians  and  through 
performance  of  assigned  NAWCTSD  device  life  cycle  support 
program  tasks  and  functions.  (Reference  (e)  applies.) 

26.  Local  Chancre  Control  Board  (LCCB)  .  An  "on-site" 
modification  review  committee,  chaired  by  the  ISEO  manager  and 
consisting  of  representatives  from  the  ISEO  and 
users/custodians,  established  to  exercise  configuration 
control  of  trainer  software  on  a  local  basis.  User/custodian 
representation  on  the  committee  will  be  requested  by  the 
chairman . 

27.  Office  of  Primary  Responsibility  (OPR) .  As  used  in 
this  document,  includes  the  project  manager  or  acquisition 
manager,  as  applicable. 

28.  Physical  Characteristics.  Quantitative  and 
qualitative  expressions  of  material  features,  such  as 
composition,  dimensions,  finishes,  form,  fit,  and  their 
respective  tolerances. 

29.  Physical  Configuration  Audit  (PCA) .  The  formal 
examination  of  the  "as-built"  configuration  of  a  Cl  against 
its  technical  documentation  to  establish  or  verify  the  Cl's 
product  baseline. 

30.  Product  Baseline  (PEL) .  The  initially  approved 
documentation  describing  all  of  the  necessary  functional  and 
physical  characteristics  of  the  configuration  item  and  the 
selected  functional  and  physical  characteristics  designated 
for  production  acceptance  testing  and  tests  necessary  for 
support  of  the  configuration  item.  In  addition  to  this 
documentation,  the  product  baseline  of  a  configuration  item 
may  consist  of  the  actual  equipment  and  software. 

31.  Software.  See  "Computer  Software"  in  DOD-STD-2167 . 

32.  Specification .  See  MIL-STD-961. 

33.  Specification  Change  Notice  (SCN) .  A  document  used 
to  propose,  transmit,  and  record  changes  to  a  specification. 
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34.  System.  See  MIL-STD-280. 

35.  Tailoring .  The  process  by  which  individual 
requirements  (sections,  paragraphs,  or  sentences)  of  a 
specification,  standard,  or  data  requirement  are  evaluated  to 
detemine  the  extent  to  which  they  are  most  suitable  for  a 
specific  system,  and  the  deletion  of  some  requirements  to 
ensure  that  each  achieves  an  optimal  balance  between 
operational  needs  and  cost. 

36.  TECD  No.  001.  TECD  No.  001  is  a  record  purpose 
baseline  document  that  provides  a  configuration  baseline 
summary  for  each  new  training  device  or  system.  In  specific 
cases  of  major  modification,  the  TECD  Baseline  Document  may  be 
assigned  a  number  other  than  001. 

37.  Technical  Data.  Technical  data  is  recorded 
information  (regardless  of  the  form  or  method  of  recording)  of 
a  scientific  or  technical  nature  (including  computer  software 
documentation)  relating  to  supplies  procured  by  an  agency. 
Technical  data  does  not  include  computer  software  or 
financial,  administrative,  cost  or  pricing,  or  management  data 
or  other  information  incidental  to  contract  administration. 

a.  Technical  data  is  required  to  define  and  document  an 
engineering  design  or  product  configuration  (sufficient  to 
allow  duplication  of  the  original  items)  and  is  used  to 
support  production,  engineering,  and  logistics  activities. 

b.  A  technical  data  package  should  include  all 
engineering  drawings,  associated  lists,  process  descriptions, 
and  other  documents  which  define  the  physical  geometry, 
material  composition,  performance  characteristics, 
manufacture,  assembly,  and  acceptance  test  procedures. 

c.  Technical  data  which  provides  instructions  for  the 
installation,  operation,  maintenance,  training,  and  support  of 
a  system  or  equipment  can  be  formatted  into  a  technical 
manual . 

(1)  A  technical  manual  normally  includes  operation 
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and  maintenance  instructions,  parts  lists  or  parts  breakdown, 
and  related  technical  information  or  procedures  exclusive  of 
administrative  procedures. 

(2)  This  data  may  be  presented  in  any  form  (e.g., 
hard  copy,  audio  and  visual  displays,  magnetic  tape,  disks,  or 
other  electronic  devices) . 

(3)  Technical  orders  that  meet  the  criteria  of  this 
definition  may  also  be  classified  as  technical  manuals  (Title 
10,  United  States  Code,  Section  2302,  "Definitions). 

38.  Technical  Data  Package.  See  "Technical  Data". 

39.  Technical  Documentation.  See  "Technical  Data". 

40.  Technical  Reviews .  A  series  of  system  engineering 
activities  by  which  the  technical  progress  on  a  project  is 
assessed  relative  to  its  technical  or  contractual 
requirements.  The  reviews  are  conducted  at  logical  transition 
points  in  the  development  effort  to  identify  and  correct 
problems  resulting  from  the  work  completed  thus  far  before  the 
problems  can  disrupt  or  delay  the  technical  progress.  The 
reviews  provide  a  method  for  the  contractor  and  Government  to 
determine  that  the  development  of  a  configuration  item  and  its 
documentation  have  met  contract  requirements . 

41.  Trainer  Engineering  Change  Proposal  (TECP) .  A 
proposed  engineering  change  and  the  documentation  by  which  a 
training  device/system  unique  change  is  described,  justified, 
and  submitted  to  the  Government  for  approval  or  disapproval . 
(Reference  (d) ,  paragraph  3.38) 

42.  Training  Device/System.  All  types  of  maintenance 
and  operator  training  hardware,  devices,  audio-visual  training 
aids,  equipment,  systems,  and  related  software  which: 

a.  Are  used  to  train  maintenance  and  operator  personnel 
by  depicting,  simulating,  or  portraying  the  operational  or 
maintenance  characteristics  of  an  item  or  facility. 

b.  Are  kept  consistent  in  design,  construction,  and 
configuration  with  such  items  in  order  to  provide  required 
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training  capability. 

43 .  Training  Equipment  Change  Control  Board  (TECCB) . 
The  NAVMRWARCENTRASYSDIV  vehicle  for  coordination  of  COG  2"0" 
training  device/system  configuration  related  matters.  Results 
of  board  actions  represent  the  official  NAWCTSD  position 
regarding  configuration  matters.  The  board  composition, 
organization,  jurisdiction,  and  operating  procedures  are  in 
Appendix  D  of  NAWCTWDINST  4130._M. 

44.  Training  Equipment  Change  Directive  (TECD) .  A 
unique  technical  directive  issued  by  the  NAVAIRWARCENTRASYSDIV 
which  is  used  to  direct  the  accomplishment  and  recording  of 
modifications  to  cognizance  symbol  2"0"  training 
devices/systems  and  companion  software  system  items,  prepared 
using  the  format  in  NAWCTSDINST  4130. _M,  Appendix  J. 

45 .  Training  Equipment  Change  Request  (TECR) ,  NTSC 
4720/2 .  A  document  which  initially  addresses  a  requirement 
for  a  configuration  change  to  a  training  device/system.  TECRs 
are  normally  submitted  by  training  device/system  user 
activities/  custodians,  or  by  NAWCTSD  ISEOs.  (Reference  (j) 
applies . ) 

46.  Training  Equipment  Model  Manager  (TEMM) .  For 
surface  trainers  only,  this  is  a  NAVEDTRACOM  activity, 
designated  by  the  Chief  of  Naval  Education  and  Training  that 
is  responsible  for  reviewing  weapon  system/platform  changes 
for  applicability  and  specific  training  systems  impact 
assessment . 

47.  Validation.  The  process  by  which  the  preparing 
activity  tests  a  technical  directive  for  accuracy  and 
adequacy . 

48.  Version.  An  identified  and  documented  body  of 
software.  Modifications  to  a  version  of  software  (resulting 
in  a  new  version)  require  configuration  management  actions  by 
either  the  contractor,  the  Government,  or  both. 

49.  Waiver .  A  written  authorization  to  accept  an  item. 
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which  during  manufacture,  or  after  having  been  submitted  for 
Government  inspection  or  acceptance,  is  found  to  depart  from 
specified  requirements,  but  nevertheless  is  considered 
suitable  for  use  "as  is"  or  after  repair  by  an  approved 
method . 

50.  Weapon  Svstem/Platf orm  Change.  An  Engineering 
Change  Proposal  (ECP) ,  Ordnance  Alteration  (ORDALT) ,  Ship 
Alteration  (SHIPALT) ,  Airframe  Change  (AFC) ,  or  similar  change 
affecting  an  operational  system  or  its  logistic  support.  Such 
changes  may  or  may  not  address  training  systems  used  in 
support  of  such  operational  equipment. 

51.  Work  Breakdown  Structure  (WBS) .  See  MIL-STD-881. 

52.  Work  Breakdown  Structure  Element .  See  MIL-STD-881 . 
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APPENDIX  D 


NASA  CM  POLICY  NSTS  07700 
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1.0  INTRODUCTION 


1.1  PURPOSE 

This  document  defines  the  requirements,  responsibilities,  and  procedures  for  all  Space 
Shuttle  Program  elements/projects  in  the  application  of  configuration  management  on 
the  Space  Shuttle  Program. 

All  program  level  configuration  management  requirements  for  the  Space  Shuttle 
Program  are  contained  herein.  In  the  event  of  conflicting  statements  regarding  configu¬ 
ration  management  requirements  between  this  volume  and  any  other  SSP  document, 
the  requirement  of  this  document  shall  take  precedence.  However,  if  a  Program  Direc¬ 
tive  has  been  subsequently  issued  by  the  Director,  Space  Shuttle  Operations,  which 
affects  the  statement(s)  in  question,  the  Program  Directive  shall  take  precedence. 

1.2  SCOPE 

This  document  has  been  jointly  developed  by  the  NASA  Centers,  and  represents  a 
careful  application  of  the  experience  gained  in  previous  NASA,  military,  and  commercial 
space  and  aircraft  programs.  The  requirements,  responsibilities,  and  procedures 
defined  herein  are  applicable  to  all  organizations  and  personnel  involved  in  the  Space 
Shuttle  program.  This  volume  also  defines  those  requirements,  responsibilities,  and 
procedures  applicable  to  contractor  activities  necessary  to  achieving  total  program  con¬ 
figuration  management  objectives. 
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3.0  CONFIGURATION  IDENTIFICATION 


Configuration  identification  determines  the  manner  in  which  the  requirements  for  and 
configuration  of  all  program  hardware/software  is  described  and  the  documentation  of 
these  descriptions.  Configuration  identification  for  the  SSP  shall  be  accomplished 
through  the  development  of  formal  documentation,  defined  herein,  which  will  describe 
the  baseline  to  be  used  for  planning  purposes  and  for  control  and  accounting  of  future 
changes.  Refer  to  Appendix  E  for  requirements  and  guidance  in  respect  to  Contract 
End  Item  (CEI)  specifications,  drawings  and  associated  lists  selection,  identification  and 
preparation.  Two  general  types  of  baselines  shall  be  addressed,  i.e.,  “NASA  baseline" 
and  “design  activity/contractor  baseline."  These  requirements  will  be  imposed  upon  the 
appropriate  design  activity/contractor  by  the  responsible  NASA  project  office/organiza¬ 
tion. 


3.1  NASA  BASELINE 

3.1.1  NASA  Requirements  Baseline 

This  baseline  shall  be  defined  by  the  documentation  that  describes  the  current  NASA 
approved  technical  and  management  requirements  (reference  Figure  3-1).  The  NASA 
requirements  shall  be  described  and  controlled  in  program  and  project  documentation 
as  follows: 

Area  of  Responsibility  Management  Responsibility 

Program  Requirements  Director,  Space  Shuttle  Operations, 

Manager.  Launch  Integration,  KSC 

Project  Requirements  Project  Managers 

Initially,  the  NASA  baseline  consists  primarily  of  program  management  and  system  per¬ 
formance  requirements.  As  the  development  effort  matures,  the  end  item  requirements 
(Orbiter,  External  Tank,  etc.)  are  defined,  baselined,  and  controlled.  Each  of  the  lower 
level  baseline  documents  are  compatible  with  the  requirements  of  the  higher  level  base¬ 
line  documents  and  shall  further  define,  as  necessary,  those  applicable  requirements. 
The  baselines  are  expanded  during  the  development  effort  as  requirements  mature. 

The  amount  of  information  to  be  contained  in  the  baselines  is  determined  on  an  indi¬ 
vidual  basis. 

At  the  appropriate  time,  a  design  freeze  of  the  Shuttle  System  configurations  is  estab¬ 
lished  to  eliminate  unnecessary  changes  and  to  preserve  the  Shuttle  System 
configuration  which  was  verified  through  the  development  and  Orbital  Flight  Test 
phases  of  the  program.  At  this  time  the  NASA  baseline  is  expanded  to  include  the  pro¬ 
duction  drawings  and  a  complete  description  of  the  product  physical  and  functional 
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configuration.  Change  approval  authority  for  Class  I  changes  (reference  Paragraph 
4.1)  to  the  baseline  is  elevated  to  the  SSP  and  selectively  delegated  to  the  Projects. 
Changes  approved  by  the  Projects  are  subsequently  reviewed  by  the  Space  Shuttle 
Program  for  system  implications. 

The  specifications  for  the  Space  Shuttle  System  and  its  elements  shall  consist  of  the 
documents  shown  in  Figure  3-2. 

The  preceding  describes  a  “progressive”  baseline  that  is  fundamental  to  the  Space 
Shuttle  Program  configuration  management  approach.  A  graphical  representation  of 
this  “progressive"  baseline  is  shown  in  Figure  3-3. 

The  drawings  and  documents  reflected  in  the  Space  Shuttle  Top  Assembly  Drawing 
Tree  (Figure  3-4)  constitute  the  Space  Shuttle  Program  baseline  requirements  for 
design  and  construction  of  the  Shuttle  System.  These  requirements  shall  be  imple¬ 
mented  by  all  affected  Shuttle  System  design  and  Operation  and  Maintenance  (O&M) 
activities.  Implementation  and  change  control  responsibilities  are  defined  in  Appendix 
Q. 

Program  freeze  points  are  established  at  specific  intervals  for  each  flight.  The  freeze 
points  are  defined  in  NSTS  07700,  Volume  III,  Flight  Definition  and  Requirements  Direc¬ 
tive. 

3.1.2  NASA  Acceptance  Baseline 

The  as-built  configuration  of  the  flight  hardware/software  is  documented  by  the 
accepting  Space  Shuttle  Program/project  element  at  the  acceptance  review.  The  NASA 
Space  Shuttle  Program  control  of  the  flight  hardware/software  commences  with  the 
acceptance  review,  and  changes  subsequent  to  acceptance  (DD-250)  of  hardware/soft¬ 
ware  will  require  authorization  by  the  Space  Shuttle  PRCB.  Configuration  control  of 
accepted  flight  hardware/software,  including  delegated  authority,  is  defined  in  Para¬ 
graph  4.2  and  subparagraphs. 

3.1.3  (Deleted) 

3.1.4  Space  Shuttle  Program  Baseline 

The  SSP  baseline  documentation  shail  contain  program  requirements.  Space  Shuttle 
management  requirements,  system  technical  requirements,  descriptive  documentation, 
and  indentured  parts  listings  and  other  identification  documents  describing  the  configu¬ 
ration  of  ail  Space  Shuttle  flight  hardware/software.  These  baseline  requirements  may 
be  apportioned  to  the  program  elements/projects,  by  the  Director,  Space  Shuttle  Opera¬ 
tions.  The  documentation  shail  contain  the  following  types  of  data: 


Volume  IV  -  Book  1 
Revision  G 


3-2 


CHANGE  NO.  129 


a.  Program  definition 

b.  Program  characteristics 

c.  Program  interface  requirements 

d.  Program  verification  requirements 

e.  System  responsibility  allocations 

f.  System  schedules 

g.  System  budget  and  cost  allocations 

h.  Management  system  requirements 

i.  Information  systems  requirements 

j.  System  design  and  performance  requirements 

k.  System  interface  requirements,  excluding  interfaces  to  be  controlled  by  a  single 
project  office 

l.  System  verification  (acceptance,  certification)  requirements 

m.  Standard  design,  construction,  assembly  and  installation  requirements  appli¬ 
cable  to  the  total  system 

n.  Other  applicable  allocated  requirements 
0.  Training  requirements 

р.  Acceptance  baseline  configuration  descriptions  and  indentured  parts  listings  for 
flight  hardware/software  that  has  had  an  acceptance  review 

3.1.5  Project  Baseline 

The  Project  baseline  documentation  shall  contain  specific  requirements  applicable  to 
the  particular  project;  e.g.,  SoHd  Rocket  Booster  (SRB),  Orbiter/GFE,  Space  Shuttle 
Main  Engine  (SSME),  etc.  This  documentation  shall  contain  the  following  types  of 
information: 

a.  Space  Shuttle  Program  requirements 

b.  Design  and  performance  requirements 

с.  Interface  requirements 

d.  Verification  requirements 
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e.  Design,  construction,  assembly  and  installation  standards  and  specifications 

f.  Training  requirements 

g.  Design  concepts,  approaches,  and  solutions  at  the  appropriate  time 

h.  Product  configuration  descriptions  at  the  appropriate  time 

3.1.6  Space  Shuttle  Program  Definition  and  Requirements  Saseirne 
Documentation 

The  SSP  baseline  is  included  in,  attached  to,  or  referenced  from  NSTS  07700,  Volumes 
I  through  XVIII,  Space  Shuttle  Program  Definition  and  Requirements.  The  Space 
Shuttle  Program  Definition  and  Requirements  baseline  documentation  is  identified  for 
reference  in  the  foreword  to  this  document.  The  content  of  each  volume  is  described  in 
NSTS  07700,  Volume  I,  Program  Description  and  Requirements  Baseline.  All  SSP  doc¬ 
umentation  will  be  baselined  and  controlled  in  accordance  with  the  requirements  and 
procedures  contained  in  this  document. 

Preparation,  Coordination,  and  Processing  of  Baseline  Documents 

An  OPR  will  be  assigned  for  each  SSP  baseline  document.  The  OPR  will  manage  the 
preparation  and  coordination  of  the  requirements  to  be  included  in  its  assigned  volumes 
and,  as  necessary  coordinate  drafts  up  to  and  including  a  final  draft  of  the  volume  to  be 
recommended  for  baselining.  This  final  draft  shall  be  submitted  for  baselining  via  a 
SSP  Change  Request  (CR).  Detailed  requirements  and  procedures  for  preparing,  coor¬ 
dinating,  and  processing  SSP  baseline  documents  are  provided  in  Paragraph  4.4.3  and 
Appendix  C  of  this  volume.  Specific  requirements  and  procedures  for  preparing,  coordi¬ 
nating,  and  baselining  SSP  Interface  Control  Documents  (ICDs)  are  provided  in 
Paragraph  3.1.8  and  Appendix  D  of  this  volume. 

3.1.8  Interface  Control  Documents 

ICDs  shall  be  used  to  control  interfaces  between  two  or  more  participating  contractors 
and  government  agencies.  Authority  for  control  of  these  documents  is  as  follows: 

a.  SSP  interfaces  which  depict  hardware/software  interfaces  between  Projects 
shall  be  controlled  by  the  Director,  Space  Shuttle  Operations.  Interfaces 
between  Space  Shuttle  flight  elements  as  approved  by  the  SSP  for  imple¬ 
mentation  in  the  Shuttle  Avionics  Integration  Laboratory  (SAIL)  shall  be 
documented  in  addenda  to  corresponding  flight  ICDs.  SAIL  ICD  addenda  shall 
be  controlled  by  the  SAIL  Configuration  Control  Panel  (CCP)  to  the  extent  spe¬ 
cified  in  Paragraph  4.3.3.2.I.  In  addition,  processing  of  Payload  ICDs  which 
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4.0  CONFIGURATION  CHANGE  CONTROL 


After  a  baseline  is  established,  it  is  essential  that  effective,  positive  control  be  estab¬ 
lished  to  preclude  any  unauthorized  changes  to  that  baseline.  There  must  be 
procedures  to  insure  that  each  proposed  change  to  the  baseline  is  completely 
described  (including  impacts):  is  thoroughly  coordinated,  reviewed,  and  evaluated;  and 
is  authorized  and  implemented  in  an  approved  manner.  Procedures  also  must  insure 
that  changes  to  a  baseline  are  not  accepted  or  implemented  that  have  not  been  pro¬ 
cessed  in  this  prescribed  manner. 

Control  of  the  Space  Shuttle  requirements  and  acceptance  baselines  and  changes 
thereto  is  to  be  through  the  use  of  Configuration  Control  Boards  (CCBs)  and  the  appli¬ 
cable  baseline  documentation  as  defined  in  Paragraph  3.0.  The  various  configuration 
control  levels  for  the  Space  Shuttle  Program  are  depicted  in  Figure  4-1. 

4.1  CHANGE  CLASSIFICATION 

All  changes  shall  be  classified  as  either  "Class  I”  or  "Class  11".  All  "Class  I”  changes 
must  receive  NASA  approval  prior  to  implementation.  "Class  il”  changes  shall  be  dis- 
positioned  by  the  contractor’s  Change  Control  System  and  do  not  require  NASA 
approval.  The  NASA  shall  concur  on  the  assigned  classification  of  each  change. 

After  implementation  of  the  design  freeze  all  subsequent  Shuttle  System  production 
hardware/software  shall  be  built  in  accordance  with  the  design  freeze  configuration 
baseline  except  for  changes  or  waivers  specifically  authorized  as  defined  herein.  Pro¬ 
posed  changes  to  the  design  freeze  baseline  shall  be  classified  as  Class  I  or  Class  II  in 
accordance  with  the  following  criteria. 

4.1.1  Class  I  Change 

Changes  shall  be  classified  as  Class  I  according  to  the  criteria  in  Paragraphs  4.1 .1.1 
and  4.1 .1 .2  below.  For  each  program  element  4.1.1 .1  shall  apply  before  and  4.1 .1 .2 
shall  apply  after  the  design  freeze  is  established.  The  design  freeze  shall  be  estab¬ 
lished  for  the  following  hardware/software: 

a.  Orbiter  -  all  flight  and  production 

b.  SSME  -  all  flight  and  production 

c.  External  Tank  -  all  lightweight  tanks 

d.  Solid  Rocket  Booster  -  all  flight  and  production 

e.  Redesigned  Solid  Rocket  Motor  -  all  flight  and  production 

f.  (Deleted) 
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g.  Flight  Support  Equipment  -  standard  crew  equipment 

h.  Orbiter  Primary  Avionics  Software  Version  19  and  Subs 

i.  Orbiter  Backup  Flight  Software  Version  12  and  Subs 

j.  KSC  Launch  Processing  System  (LPS),  Checkout,  Control,  and  Monitoring 
Subsystem  (CCMS),  and  interfacing  GSE  software 

k.  Payload  checkout  and  launch  software 

After  the  design  freeze  is  established  all  changes  meeting  the  criteria  of  Paragraph 
4. 1.1. 2  shall  require,  as  a  minimum,  disposition  by  the  appropriate  Project  CCB.  The 
Project  CCBs  are  authorized  to  approve  changes  which  do  not  affect  the  criteria  of 
Paragraph  4.3.2. 1  and  which  are: 

a.  Make  work/make  safe  (required  for  proper  fit  or  function  or  to  eliminate  an 
unacceptable  safety  hazard) 

b.  Mission  unique  (required  to  configure  system  for  a  specific  mission) 

c.  High  payback  (results  in  significant  net  cost  savings,  performance  increases,  or 
turnaround  time  reductions) 

d.  Necessary  to  add  a  new  capability  to  the  Shuttle  System  to  meet  an  approved 
mission  requirement 

4.1. 1.1  Pre-Design  Freeze 

Before  the  design  freeze  is  established  for  a  system  element,  a  change  shall  be  classi¬ 
fied  as  “Class  I"  when  any  of  the  following  are  affected: 

a.  Requirements  contained  in  the  NASA  baseline 

b.  Contract  provisions 

c.  Configuration  of  hardware/software  accepted  by  NASA  including  test  articles 
intended  for  major  integrated  tests 

d.  The  following  documentation  for  a  particular  configuration  of  hardware  after  that 
configuration  has  been  certified: 

1 .  Engineering  drawings 

2.  Engineering  materials  and  process  specifications 

3.  Engineering  acceptance  test  requirements 

4.  Certification/verification  requirements 
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4.1. 1.2  Post-Design  Freeze 

After  the  design  freeze  is  established  a  change  to  flight  hardware/software  shall  be 
classified  as  “Class  I"  when  any  of  the  following  are  affected; 

a.  Requirements  contained  in  the  formal  NASA  Space  Shuttle  Program  or  Project 
baseline  documentation 

b.  Space  Shuttle  Program  or  Project  schedule  milestones 

c.  Contract  cost 

d.  Contract  provisions 

e.  Configuration  of  hardware/software  accepted  by  NASA  including  test  articles 
intended  for  major  ground  test  (reference  Paragraph  4.2) 

f.  Government  furnished  hardware 

g.  Interchangeability  (as  defined  in  Paragraph  4.4.1 3.5)  with  the  design  freeze 
configuration  baseline  of  components  or  assemblies  of  production  hardware/ 
software  not  yet  accepted  by  NASA 

h.  Crew  procedures  or  training 

i.  Flight  planning 

j.  Mission  Control  Center  hardware/software 

k.  Qualification/certification  status 

l.  GSE,  facilities  or  trainers 

m.  Requirements  and  procedures  defined  in  NSTS  08171,  Operations  and  Mainte¬ 
nance  Requirements  and  Specifications  Document  (OMRSD)  or  Operations 
and  Maintenance  Instructions  (OMIs) 

n.  Change  in  procurement  source  of  any  item  at  any  level  defined  by  source  con¬ 
trol  drawings 

o.  Critical  process  per  NHB  5300.4  (1 D-2) 

p.  Functional  or  performance  characteristics  different  from  that  previously  docu¬ 
mented  or  demonstrated  in  actual  operations 

4.1.2  Class  II  Change 

Any  change  which  does  not  fall  within  the  Class  I  definition  shall  be  designated  as 
Class  II. 
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4.2  CONFIGURATION  CONTROL  OF  ACCEPTED  FLIGHT  HARDWARE/SOFTWARE 

To  facilitate  synchronization  of  the  Space  Shuttle  System  configuration  among  the  var¬ 
ious  program  elements/projects  and  to  assure  a  coordinated,  timely  reaction  of  all 
program  elements/projects  to  necessary  changes  to  the  configuration  of  flight  hardware/ 
software  after  NASA  acceptance  (DD-250),  all  configuration  changes  and  requests  for 
performance  of  non-standard  work  will  require  authorization  by  the  Space  Shuttle  Pro¬ 
gram  or,  where  applicable,  the  delegated  project.  This  authorization  will  be  obtained 
prior  to  issuance  of  work  authorization  at  the  using  site.  The  mechanisms  for  disposi- 
tioning  these  changes  are  the  Space  Shuttle  PRCB,  Special  Daily  Space  Shuttle  PRCB 
(reference  Paragraph  4.4.13.6),  or  the  appropriate  Project  CCB.  Changes  that  do  not 
meet  the  criteria  of  Paragraph  4.4.13.6,  such  as  drawing  corrections,  clarifications, 
addition  of  true  alternate  parts,  and  non— mandatory  flow  enhancement  changes  (which 
relax  assembly  requirements  but  meet  SSP  requirements)  can  be  dispositioned  by  the 
Project  CCB.  Emergency  changes  to  accepted  flight  hardware/software  may  be  imple¬ 
mented  in  accordance  with  Paragraph  4.4.3.2.1, 

Configuration  changes  which  violate  any  of  the  SSP  criteria  defined  below  (a  -  g)  must 
be  fonwarded  to  the  Space  Shuttle  Program  for  disposition.  Other  configuration  change 
approvals  are  delegated  to  the  projects  as  defined  in  Paragraphs  4.2.1,  4.2.2  4  2  3  and 
4.2.4. 

a.  Impact  performance,  safety,  resources  or  major  milestone  schedules. 

b.  Affect  SSP  interface  control  document  requirements. 

c.  Cannibalization  of  flight  hardware. 

d.  Changes  associated  with  resolution  of  major  anomalies  or  incid^ts,  or 
changes  which  are  deemed  significant  to  the  program. 

e.  Engineering  or  hardware  required  to  incorporate  the  change  will  not  meet  the 
specified  site  need  date. 

f.  A  flight  hardware  change  that  impacts  any  level  of  assembly  interchangeability 
(Paragraph  4.4.13.5). 

g.  Impacts  other  projects  (except  as  delegated  in  Paragraphs  4.2. 1  and  4.2.4)  or 
program  elements,  I.e.,  mission  operations,  flight  crew  operations,  flight  soft¬ 
ware,  Launch  Commit  Criteria  (LCC),  etc. 

Requests  for  non-standard  work  performed  at  the  launch  site  which  violate  the  criteria 
defined  in  Paragraph  4.4.13.7a,  must  be  forwarded  to  the  Space  Shuttle  Program  for 
disposition. 


Volume  IV  -  Book  1 
Revision  G 


4-4 


CHANGE  NO.  129 


5.0  CONFIGURATION  ACCOUNTING 


Configuration  accounting  is  the  element  of  Configuration  Management  (CM)  that  pro¬ 
vides  the  essential  records  and  reporting  of  precise  configuration  data  for  ail  Space 
Shuttle  hardware/software.  The  primary  objectives  of  configuration  accounting  are  as 
follows: 

a.  To  maintain  and  disseminate  the  current  configuration  data  of  each  program/ 
project  element 

b.  To  maintain  correlation  among  the  configuration  data  for  various  equipment, 
software,  and  support  elements 

c.  To  maintain  current  and  accurate  records  of  the  status  of  changes  completed 
and  in  process 

The  configuration  accounting  system  shall  include  the  task  of  maintaining,  storing,  and 
correlating  configuration  documentation  of  all  hardware/software.  This  includes  activi¬ 
ties  required  to  receive  inputs  from  the  design  activity  release  desk  (as-designed), 
quality  control  (as-built),  and  other  sources  (i.e.,  as-tested,  as-qualified,  as-delivered, 
as-flown,  etc.):  and  to  compare,  summarize,  and  produce  configuration  summaries,  dif¬ 
ferences,  and  other  comparison  data  as  may  be  of  value  to  various  program 
organizations. 


5.1  ICD  CROSS-REFERENCE  SYSTEM 

Each  design  activity/contractor  shall  maintain  a  system  that  indicates  which  engineering 
drawings  are  affected  by  Space  Shuttle  Program  and  project  ICDs.  This  system  will 
allow  the  designer  or  other  affected  parties  to  determine  which  drawings  and/or  ICDs 
may  be  affected  by  a  proposed  change. 


5.2  SPACE  SHUTTLE  INTEGRATED  PROGRAM  ICD  STATUS 

The  Space  Shuttle  Program  shall  utilize  the  NASA  Open  IRN  Report  and  the  Historical 
IRN  Report  which  reside  in  the  TDMS  2  data  base.  Current  and  historical  data, 
including  latest  ICD  revision  and  IRN  incorporation  are  available  on-line  in  TDMS  2. 

The  Space  Shuttle  Program  shall  utilize  the  payload  Preliminary  Interface  Revision 
Notice  (PIRN)/IRN  Report  which  resides  in  the  Automated  Mission  and  Payload 
Tracking  System  (AMPTS)  for  current  payload  ICD  information. 
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5.3  PROGRAM  DOCUMENT  DESCRIPTION  AND  STATUS  REPORT 

The  Space  Shuttle  Program  shall  utilize  NSTS  08102,  Program  Document  Description 
and  Status  Report,  which  is  a  listing  of  current  revisions  and  changes  to  all  SSP  base¬ 
line  documents.  This  report  will  be  used  to  identify  the  status  of  the  NASA  baseline 
documentation.  Applicable  projects,  design  activities  and  contractors  shall  be  furnished 
NSTS  08102  to  review  and,  if  necessary,  to  redline  changes  to  the  document.  NSTS 
08102  shall  be  maintained  by  the  Space  Shuttle  Management  Integration  Office. 

5.4  CONFIGURATION  STATUS  REPORTING 

Configuration  accounting  and  verification  functions  shall  maintain  or  have  access  to 
complete  and  accurate  records  on  the  location  and  configuration  status  of  all  Contractor 
Furnished  Equipment  (CFE),  GFE,  and  commonality  items  of  equipment.  The  records 
will  include  such  data  as  nomenclature,  manufacturer’s  identification,  required  and 
scheduled  delivery  dates  for  modification  kits,  planned  and  actual  usage  of  each  serial 
number,  and  additional  notes  as  required. 

Records  will  be  monitored  by  each  project  on  the  status  of  changes  being  managed  by 
the  project.  These  records  will  enable  an  audit  trail  to  be  accomplished,  from  accep¬ 
tance  of  each  CR  through  verification  of  change  implementation.  The  records  will 
include  a  cross-reference  to  the  following,  where  required: 

a.  CRs 

b.  Change  proposals 

c.  NASA  Configuration  Control  Board  Directives  (CCBDs) 

d.  Baseline  documentation  status 

e.  ICD  status 

f.  Technical  directives 

g.  Contract  Change  Authorization  (CCA)  (if  applicable) 

h.  Retrofit/Modification  kits 

Status  accounting  reports  will  be  used  to  support  acceptance  and  delivery  of  hardware/ 
software  as  well  as  reviews  and  inspections. 

The  foregoing  elements  of  data  (as  a  minimum)  shall  be  maintained  by  the  design  activity/ 
contractor  and  shall  be  a  product  of  the  configuration  accounting  system.  Appropriate 
summaries,  evaluations,  and  status  reports  will  be  prepared  from  this  data  for  submittal 
to  the  NASA  as  required. 
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5.5  MISSION  EQUIPMENT  CONFIGURATION  ACCOUNTING 

Mission  equipment  installation  requirements  for  each  Space  Shuttle  flight  are  specified 
in  the  MECSLSI  drawing  and  the  CCCD  for  that  flight.  The  configuration  accounting 
system  which  shall  be  used  to  track  mission  equipment  assets,  status  compliance  with 
the  MECSLSI  and  CCCD  drawing  requirements  and  provide  associated  reports  is 
defined  in  Appendix  R. 

5.6  MISSION-ESSENTIAL  SOFTWARE  DATA  RETENTION 

Mission-essential  software  elements  (GPC,  SSME,  LPS  and  Mission  Control  Center 
[MCC])  shall  retain  “as  flown”  software  configurations  (executable  code,  mission-unique 
data,  and  related  documentation)  for  a  minimum  of  three  years.  Refer  to  NSTS  07700, 
Volume  XVIII,  Book  3,  Computer  Systems  and  Software  Requirements,  Software  Man¬ 
agement  and  Control,  for  further  details. 
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6.0  CONFIGURATION  VERIFICATION 

Configuration  management  includes  activities  associated  with  assuring  that  require¬ 
ments  are  properly  implemented  and  hardware/software  is  certified  as  having  been 
designed  and  built  to  the  correct  configuration.  This  effort  shall  be  an  intrinsic  part  of 
the  overall  management  approach  on  the  program. 

6.1  SSP  REQUIREMENTS  VERIFICATION 

The  Space  Shuttle  Program,  having  authority  for  the  development  and  control  of  the 
NASA  baseline,  shall  ensure  that  all  external  agency  requirements  and  interfacing 
requirements  between  program  elements/projects  have  been  properly  incorporated  into 
the  baseline.  Requirements,  design,  and  hardware/software  configuration  reviews  will 
be  conducted  as  necessary  to  ensure  that  this  is  accomplished.  These  reviews  also  will 
be  used  to  establish  baselines  for  further  development  of  requirements  and  to  validate 
the  approaches  taken  to  the  solution  to  these  requirements.  The  reviews  considered  to 
be  SSP  requirements  are  defined  in  the  following  subparagraphs. 

6.1.1  Program  Requirements  Review  (PRR) 

This  review  encompasses  all  major  SSP  participants  and  is  chaired  by  the  Director, 
Space  Shuttle  Operations,  or  delegated  representative.  The  purpose  of  the  review  is  to 
review  and  update  program  requirements  and  evaluate  the  management  techniques, 
procedures,  agreements,  etc.,  to  be  utilized  by  all  participants.  This  review  evaluates 
CM  procedures  and  formats  required  to  satisfy  the  program  requirements. 

6.1.2  Shuttle  System  Requirements  Review  (SRR) 

This  review  encompasses  all  major  SSP  participants  and  is  chaired  by  the  Director, 
Space  Shuttle  Operations,  or  delegated  representative.  The  purpose  of  this  review  is  to 
update  the  program  and  system  requirements  to  be  utilized  by  the  contractors  for  the 
SSP.  These  requirements  are  documented  as  the  NASA  SSP  baseline  (reference 
Paragraph  3.1.4),  implemented  with  the  contractors,  and  placed  under  configuration 
change  control. 

In  addition  to  the  system  requirements,  other  program  element  requirements  may  be 
reviewed  and  evaluated  to  ensure  they  conform  to  the  system  requirements  and  that 
contractors  have  correctly  interpreted  the  NASA  requirements  for  the  program  ele¬ 
ments. 

Prior  to  or  at  the  SRR,  ICD  responsibilities  will  be  defined  and  documented  and  master 
schedules  for  ICD  completion  will  be  established. 

6.1.3  Preliminary  Design  Reviews  (PDRs) 

Preliminary  Design  Reviews  will  be  conducted  by  each  responsible  NASA  Project  office 
with  their  NASA  in-house  design  activity/contractor,  prior  to,  or  very  early  in  the  detail 
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design  phase.  The  PDR  is  a  technical  review  of  the  basic  design  approach  for  configu¬ 
ration  items  and  for  selected  major  changes  to  these  items  to  assure  compatibility  with 
the  SSP  and  Project  requirements  (including  interface  requirements)  and  the  produci- 
bility  of  the  design  approach.  Cost  and  schedule  relationships  also  will  be  reviewed. 
This  review  will  update  the  Project  requirements  to  be  utilized  by  the  NASA  in-house 
design  activities/contractors  for  the  applicable  Project.  These  requirements,  including 
those  contained  in  the  Statement  of  Work/Requirements,  shall  be  documented  as  the 
NASA  Project  baseline,  implemented  with  the  NASA  in-house  design  activity/con¬ 
tractor,  and  placed  under  configuration  change  control.  In  the  event  Project 
requirements  have  been  baselined  prior  to  PDR,  they  will  be  updated  as  required  to 
incorporate  the  applicable  results  of  the  PDR. 

All  ICDs  applicable  to  a  PDR  should  be  baselined  to  reflect  appropriate  interface 
requirements  prior  to  PDR  completion.  When  any  PDR  is  completed,  all  applicable 
ICDs  must  be  baselined  and  implemented  with  the  affected  contractors  and  placed 
under  configuration  change  control. 

Typically,  the  items  for  review  at  the  PDR  should  include  the  following: 

a.  Preliminary  ICDs 

b.  Design  analyses 

c.  Layout,  general  arrangement,  and  envelope  drawings 

d.  Schematics  and  block  diagrams 

e.  Sizing,  trade  study,  and  design  study  results 

f.  Material  and  process  specification  listings 

g.  Applicable  procurement  specifications 

h.  Test  requirements 

i.  Mockups  and  models 

j.  Updated  plans,  procedures,  and  schedules 

k.  Commonality  candidates;  identification,  rationaie,  and  status 

l.  Proposed  additions  to  the  NASA  baseline 

m.  Selected  SR&QA  documentation  (FMEAs,  CILs,  hazard  analyses,  etc.) 

The  PDR  should  result  in  the  authorization  to  the  contractor  to  proceed  with  further 
design  in  accordance  with  the  reviewed  design  approach,  interface  requirements,  com¬ 
monality  items,  etc.,  and  approval  or  update  of  the  project  baseline  documentation. 
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SUMMARY 


A  comprehensive  software  control  and  system  configuration  management  process 
for  flight-critical  digital  control  systems  of  advanced  aircraft  has  been  developed 
and  refined  to  ensure  efficient  flight  system  development  and  safe  flight  operations 
Because  of  the  highly  complex  interactions  among  the  hardware,  software,  and  system 
elements  of  state-of-the-art  digital  flight  control  system  designs,  a  systems-wide 
approach  to  configuration  control  and  management  has  been  used*  Specific  procedures 
are  implemented  to  govern  discrepancy  reporting  and  reconciliation,  software  and 
hardware  change  control,  system  verification  and  validation  testing,  and  formal  doc¬ 
umentation  requirements*  An  active  and  knowledgeable  configuration  control  board 
reviews  and  approves  all  flight  system  configuration  modifications  and  revalida¬ 
tion  tests-  This  report  includes  examples  of  configuration  management  forms  and  a 
description  of  the  tracking  process  which  ensures  accurate  and  consistent  records. 
This  flexible  process  has  proved  effective  during  the  development  and  flight  test¬ 
ing  of  several  research  aircraft  and  remotely  piloted  research  vehicles  with  digital 
flight  control  systems  that  ranged  from  relatively  simple  to  highly  complex,  inte¬ 
grated  mechanizations. 


INTRODUCTION 


The  complex  and  integrated  nature  of  the  flight-critical  digital  control  sys¬ 
tems  of  advanced  aircraft  necessitates  a  rigorous  software  control  and  system  con¬ 
figuration  management  process  to  ensure  efficient  flight  system  development  and  safe 
flight  operations.  Over  the  past  10  years,  the  Dryden  Flight  Research  Facility  of 
NASA  Ames  Research  Center  has  developed  and  refined  a  comprehensive  configuration 
management  process,  which  has  been  applied  to  several  research  aircraft  and  remotely 
piloted  research  vehicles  with  digital  flight  control  systems  that  ranged  from  rela¬ 
tively  simple  to  complex  and  highly  integrated  mechanizations.  This  flexible  proc¬ 
ess  has  proved  effective  for  the  F-8  digital  fly-by-wire  (DFBW)  and  the  highly  inte¬ 
grated  advanced  fighter  technology  integration  (AFTI)  F— 16  research  aircraft,  as 
well  as  the  3/8-scale  F-15  spin  research  vehicle  (SRV),  the  highly  maneuverable  air¬ 
craft  technology  (HiMAT),  and  the  drones  for  aerostructural  testing  (DAST)  remotely 
piloted  research  vehicles. 

Various  methods  and  approaches  for  software  control  and  system  configuration 
management  have  been  used  successfully,  and  many  have  been  published  in  the  lit¬ 
erature.  All  systems  have  some  unique  and  dominant  characteristics;  advanced  air¬ 
craft  flight  control  systems  are  no  exception.  Because  of  the  highly  complex  inter¬ 
actions  among  the  hardware,  software,  and  system  elements  of  a  state-of-the-art  dig¬ 
ital  flight  control  system  design,  a  systems-wide  configuration  control  and  manage¬ 
ment  process  is  necessary.  Experience  with  the  development  of  various  advanced 
flight  systems  has  shown  that  use  of  separate  hardware  and  software  configuration 
control  procedures  is  ineffective  for  highly  integrated  flight  systems  in  that  many 
of  the  difficult  design,  development,  and  testing  issues  involve  interactions  bet¬ 
ween  hardware  and  software  systems. 

This  paper  describes  the  process  and  procedures  of  a  highly  successful  and  effi¬ 
cient  software  control  and  system  configuration  management  technique  for  advanced 
aircraft  digital  flight  control  systems.  Experience  with  several  advanced  vehicle 
systems  is  described,  and  specific  examples  are  given  to  illustrate  the  implemen¬ 
tation  process. 


NOMENCLATURE 


AFTI 

CCR 

DAST 

DFBW 

DR 

HiMAT 

PC 

RAV 

SRV 

STR 

WO 


advanced  fighter  technology  integration 
configuration  change  request 
drones  for  aerostructural  testing 
digital  fly-by~wire 
discrepancy  report 

highly  maneuverable  aircraft  technology 

program  change 

remotely  augmented  vehicle 

spin  research  vehicle 

system  test  report 

work  order 


SYSTEM  DEVELOPMENT  PHASES 


The  proper  application  of  a  successful  software  control  and  system  configuration 
management  process  requires  a  thorough  understanding  of  the  various  phases  required 
for  development  of  an  advanced  system.  The  primary  phases  for  development  of  an 
integrated  digital  flight  control  system  for  an  advanced  aircraft  are  definition  of 
requirements,  design,  production,  and  ground  and  flight  test  (fig.  1).  Recognizing 
that  all  these  phases  are  likely  to  require  interactive  development  over  the  life¬ 
span  of  a  complex  system  is  critical  in  the  implementation  of  a  configuration  naanage- 
ment  process. 

The  definition  of  requirements  typically  begins  with  specification  of  the  broad 
mission  requirements  and  culminates  with  a  conceptual  design  of  the  system.  The  con¬ 
ceptual  design  is  presented  in  a  comprehensive  system  specification  document  which 
describes  the  overall  system  characteristics,  including  the  functional  requirements 
of  the  hardware  and  software.  Other  requirements  defined  in  this  phase  include  the 
equipment  and  facilities  required  for  system  testing,  the  staffing  plan,  and  the  doc¬ 
umentation  procedures. 

The  generation  of  detailed  specification  documents  outlining  specific  system 
hardware  and  software  requirements  is  an  initial  step  of  the  design  phase.  These 
documents  must  satisfy  the  requirements  of  the  comprehensive  system  specification 
document.  During  the  design  phase,  the  overall  plan  for  software  control  and  system 
configuration  management  is  defined,  and  specific  procedures  and  responsibilities 
are  established.  A  series  of  specification  and  design  reviews  is  essential  for  the 
efficient  evolution  of  the  system  development. 
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After  the  critical  design  review  is  the  software  and  hardware  production  phase, 
which  requires  the  mechanization  of  various  tools  and  facilities.  Generally,  the 
hardware  and  software  elements  of  a  complex  system  are  initially  tested  indepen¬ 
dently  using  specialized  stand-alone  equipment  and  facilities.  After  functional  ver¬ 
ification  tests,  the  software  and  hardware  elements  are  integrated  for  final  ground 
testing,  overall  system  validation,  and  flight  qualification  tests.  A  flight  readi¬ 
ness  review  is  conducted  prior  to  flight  test  evaluations  to  assess  the  results  of 
the  various  ground  tests  and  the  flight  readiness  of  the  vehicle  and  flight  systems. 

To  properly  manage  these  phases  of  development,  an  overall  software  control  and 
system  configuration  management  process  is  needed  to  provide  consistent  treatment  of 
software  and  hardware  elements.  This  process  is  designed  to  include  both  the  soft¬ 
ware  and  hardware  elements  of  advanced  integrated  systems  and  accommodates  the  inher 
ent  iterative  nature  of  advanced  digital  flight  control  system  development.  The  con 
cept  of  a  systems-wide  approach  to  configuration  control  and  management  (which  means 
that  the  same  process  is  used  for  both  software  and  hardware  system  elements)  is  a 
primary  contributor  to  the  successful  application  of  this  process  on  a  number  of 
highly  complex  aircraft  systems. 


PROCESS  DESCRIPTION 


The  primary  purpose  of  the  software  control  and  system  configuration  management 
process  for  flight-critical  digital  flight  control  systems  is  to  provide  a  method 
for  efficient  flight  system  development  and  a  procedure  for  assuring  safe  flight 
operations.  The  process  is  designed  to  control  system  configuration  changes  by  man¬ 
aging  the  primary  system  development  phases  described  previously,  and  to  resolve  dis¬ 
crepancies  uncovered  during  system  testing-  In  addition,  the  configuration  control 
process  prescribes  stringent  test  and  documentation  requirements  and  provides  for 
visibility  of  changes  across  all  involved  engineering  disciplines  through  formal 
review  procedures . 

The  overall  software  control  and  systems  configuration  management  process 
(fig.  2)  can  be  divided  into  four  phases,  analogous  to  those  of  the  system  develop¬ 
ment  process.  Requirements  for  configuration  changes  arise  from  new  software  or 
hardware  system  requirements  or  from  discrepancies  noted  during  system  analysis  or 
test.  An  important  element  of  this  change-in-requirements  phase  is  the  documenting 
and  reporting  of  system  discrepancies.  All  system  development  personnel  are  respon¬ 
sible  for  documenting  and  reporting  all  discrepancies,  software  or  otherwise ,  found 
during  system  operation  and  test.  A  standardized  form  for  discrepancy  reporting 
aids  the  documentation  and  tracking  process.  When  the  discrepancy  is  discovered, 
the  anomalous  behavior  and  the  system  software  and  hardware  test  configuration  are 
documented  in  detail.  The  cause  of  the  discrepancy  and  the  required  fix  are  usually 
determined  at  a  later  time;  a  method  of  working  around  the  problem  or  a  temporary 
fix  may  be  incorporated  if  necessary  to  continue  testing. 

After  the  change  requirements  are  defined,  analyses  are  undertaken  to  define  and 
then  design  the  required  software  or  hardware  modifications.  For  changes  required 
as  a  result  of  a  system  discrepancy,  the  cause  and  required  fix  are  indicated  on  the 
discrepancy  report  form.  A  configuration  change  request  form  is  prepared  for  any 
change  required.  Before  being  implemented,  each  system  hardware  or  software  change 
must  be  reviewed  and  approved  by  the  configuration  control  board  which  includes  soft 
ware,  hardware,  systems,  operations,  and  management  personnel.  This  board  provides 
the  forum  for  disciplinary  and  flight  test  engineers  to  discuss  the  changes  and 
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their  impacts/  identify  test  or  retest  requirements/  and  determine  the  effects  of 
the  changes  on  operational  procedures  or  system  performance.  The  configuration  con-* 
trol  board  approves,  returns  for  further  analysis,  or  rejects  the  specific  hardware 
and  software  changes  requested  and  then  formally  documents  the  action  taken.  If  a 
system  hardware  modification  is  required,  a  work  order  form  is  prepared  to  provide  a 
detailed  description  of  the  modification.  If  a  system  software  modification  is 
required,  a  program  change  notice  is  prepared  to  describe  the  specific  change  and 
the  reason  for  and  impact  of  the  change. 

The  primary  function  of  the  software  control  and  system  conf i-guration  ^TLanagement 
process  during  the  production  phase  is  to  assure  that  proper  procedures  are  foliow^ed 
in  the  implementation  of  the  approved  changes  and  that  requirements  for  updated  doc¬ 
umentation  are  met.  A  hardware  drawing  is  updated,  and  after  fabrication,  the  modi¬ 
fication  is  inspected  for  quality  assurance  and  compliance  with  the  work  order.  The 
software  manufacturing  process  is  highly  dependent  on  the  specific  computer  equip¬ 
ment  and  software  development  tools  and  varies  greatly  from  system  to  system.  An 
important  element  common  to  all  software  production  processes  is  the  requirement  for 
adherence  to  formal  written  procedures  detailing  specific  sequences  in  the  manufac¬ 
turing  process  as  well  as  for  updating  the  formal  software  documentation. 

The  configuration  management  process  has  an  integral  function  in  the  testing 
that  follows  the  incorporation  of  any  change.  Procedures  that  govern  verification 
and  validation  test  requirements  are  implemented  for  both  software  and  hardware  mod¬ 
ifications.  Written  system  verification  and  validation  test  reports  are  required 
for  all  system  elements  and  for  all  system  changes.  The  verification  test  for  a 
hardware  change  includes  the  visual  inspection  and  continuity  check  which  determines 
that  a  hardware  item  is  constructed  and  wired  in  accordance  with  the  drawing.  Hard¬ 
ware  validation  involves  a  series  of  systems  functional  tests  which  are  performed  to 
qualify  the  design  and  its  implementation.  Software  verification  is  the  testing 
process  that  formally  assures  that  the  software  is  coded  in  accordance  with  its 
design  specification.  The  software  validation  step  assures  that  the  specified  soft¬ 
ware  change  accomplishes  the  desired  objective  within  acceptable  limits  and  operates 
correctly  in  the  operating  environment  of  the  total  system.  The  system  validation 
testing  often  uncovers  system  discrepancies  resulting  from  the  integration  of  the 
hardware  and  software.  Adherence  to  an  established  written  policy  concerning  soft¬ 
ware  reverif ication  and  system  revalidation  testing  after  a  software  change  is 
required.  The  documented  test  results  are  reviewed  by  the  configuration  control 
board  for  adequacy  and  completeness  before  the  modified  hardware  or  software  is 
released  for  pre-flight  checks  and  flight  testing  of  the  system. 

The  configuration  control  board  plays  a  vital  role  in  a  successful  software  con¬ 
trol  and  system  configuration  management  process.  The  board  assures  that  a  coordi¬ 
nated  closed-loop  process  exists  at  all  system  development  stages  by  controlling  sys 
tern  configuration  changes  arising  from  new  requirements  or  discrepancy  reconcilia¬ 
tions  and  by  reviewing  implementation  details  and  test  results.  An  active  and  knowl 
edgeable  configuration  control  board  greatly  enhances  the  efficiency  of  complex  and 
integrated  system  developments  by  maintaining  the  essential  common  thread  of  knowl¬ 
edge  and  experience. 


Documentation 

An  essential  part  of  the  software  control  and  system  configuration  management 
process  is  a  comprehensive  and  consistent  method  for  documenting  developmental 
changes.  The  primary  goal  of  this  documentation  is  to  provide  communication  and 
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therefore  visibility  of  changes  across  all  involved  engineering  disciplines.  The 
documentation  generated  during  the  validation  and  test  phases  of  the  system  develop¬ 
ment  process  provides  the  means  by  which  conformance  to  the  overall  mission  require¬ 
ments  is  tracked  and  controlled.  The  material  generated  for  the  various  design  and 
readiness  reviews  is  also  a  valuable  documentation  element. 

A  method  for  "checks  and  balances"  is  provided  on  the  forms  used  for  system  con¬ 
figuration  control  documentation  arid  tracking  (fig.  3) .  Closing  the  loop  on  the 
change  control  process  is  essential  in  the  development  of  a  complex  flight  system. 

To  assure  that  changes  are  tracked,  tested,  and  documented  properly,  the  discrepancy 
report,  configuration  change  request,  program  change,  work  order,  and  system  test 
report  forms  are  cross-referenced.  Each  form  has  a  unique  identification  number  to 
aid  this  cross-referencing  process.  Examples  of  the  forms  used  are  included  in  the 
appendix. 

The  closing  action  section  on  the  discrepancy  report  form  provides  space  for 
recording  the  configuration  change  request,  program  change,  and  work  order  numbers 
identifying  the  implemented  change.  The  configuration  change  request  form  cross- 
references  all  the  other  forms  and  is  the  primary  form  used  for  assuring  that  the 
change  has  been  implemented  and  documented  properly.  The  program  change  form  used 
for  software  changes  references  the  discrepancy  report  and  configuration  change 
request  numbers.  In  addition,  specific  software  release  identification  and  docu¬ 
mentation  updates  are  referenced  on  this  form.  The  work  order  form  includes  a  ref¬ 
erence  to  the  discrepancy  report  if  the  change  is  the  result  of  a  system  discrepancy 
and  also  provides  for  documentation  of  the  quality  assurance  inspection.  Hardware 
drawing  updates  are  generally  attached  to  the  work  order  form.  The  system  test 
report  forms  are  used  for  documenting  all  formal  system  testing  and  the  retesting 
required  after  system  changes.  For  tests  resulting  from  the  implementation  of  sys¬ 
tem  changes,  the  program  change  or  work  order  number  is  referenced. 


Status  and  Tracking 

An  advanced  flight  system  development  program  commonly  has  a  large  number  of  dis¬ 
crepancies,  changes,  and  tests  in  various  stages  of  resolution,  design  or  analysis, 
and  accomplishment,  respectively.  An  efficient  method  of  tracking  progress  and  gen¬ 
erating  status  information  is  required  for  overall  project  management  and  scheduling 
purposes.  Manual  recordkeeping  and  documentation  control  may  be  adequate  for  sim¬ 
pler  system  development  projects,  but  becomes  cumbersome  and  ineffective  on  larger, 
more  complex  projects. 

An  automated  method  for  maintaining  tracking  and  status  information  for  complex 
flight  system  configuration  modifications  has  been  developed  using  a  microprocessor- 
based  computer  system.  Standard  data-base  management  software  is  used  to  create 
files  containing  all  pertinent  information  required  to  track  system  configuration 
status.  The  computer  system  is  used  to  store,  update,  and  retrieve  information  per¬ 
taining  to  the  status  of  discrepancy  reports,  configuration  change  requests,  program 
changes,  work  orders,  and  system  verification/validation  test  reports.  Hardware 
and  software  documentation  updates  are  also  tracked.  Various  sorting  and  indexing 
methods  are  used  to  generate  hard-copy  status  reports  in  a  variety  of  formats.  This 
automated  system  has  proved  to  be  an  accurate  and  efficient  tool  in  the  overall  soft¬ 
ware  control  and  system  configuration  management  process. 
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APPLICATION  EXPERIENCE 


The  process  for  software  control  and  system  configuration  management  has  been 
applied  to  several  research  aircraft  and  remotely  piloted  research  vehicle  programs, 
including  the  F-8  DFBW,  AFTI/F-16,  HiMAT,  F-15  SRV,  and  DAST.  All  these  vehicles 
have  integrated  digital  flight  control  systems;  the  mechanization  complexity  varies 
greatly.  The  key  elements  of  the  process  were  adapted  for  specific  application  on 
each  of  these  programs,  demonstrating  the  flexibility  of  the  overall  concept.  The 
point  at  which  the  formal  configuration  control  process  begins  varies  from  program 
to  program  but  generally  starts  when  the  baseline  system  configuration  has  matured 
to  the  point  of  allowing  effici^t  formal  testing  without  undue  restrictions  or 
operational  difficulties.  The  software  control  and  system  configuration  management 
methods  described  in  the  previous  section  represent  the  current  status  of  a  continu¬ 
ally  evolving  process;  experiences  from  each  program  contribute  refinements  and 
enhance  both  the  overall  approach  and  specific  procedures.  The  process,  as  detailed 
in  figure  2,  is  certainly  not  envisioned  to  be  directly  applicable  for  all  programs; 
however,  it  has  provided  a  basic  framework  from  which  useful  configuration  control 
and  management  procedures  have  been  developed. 

The  configuration  control  process. used  on  the  highly  complex  AFTI/F-16  air¬ 
craft  was  largely  based  on  these  concepts.  Over  100  flights  were  accomplished  and 
13  major  software  releases  were  developed  and  qualified  for  the  AFTI/F-16  digital 
flight  control  systems  during  the  first  year  of  flight  testing.  More  than  330  dis¬ 
crepancy  reports  were  processed  during  the  development  and  flight  test  activity,  and 
over  95  software  program  changes  were  implemented.  Specific  details  of  the  config¬ 
uration  control  process  used  on  the  AFTI/F-16  aircraft  program  are  contained  in 
reference  1.  The  following  sections  outline  application  experience  on  the  F-8  DFBW 
and  HiMAT  research  programs;  the  experiences  with  the  F-15  SRV  and  DAST  programs 
were  similar. 


F-8  DFBW  Program 

The  F-8  DFBW  research  aircraft  was  first  flown  in  1972  with  a  simplex,  full- 
authority  digital  flight  control  system  using  ultrareliable  system  hardware  from  the 
Apollo  spacecraft  program  and  a  triply-redundant  analog  backup  system.  The  first 
flight  of  the  second  phase  of  the  F-8  DFBW  program,  which  occurred  in  1976,  used  a 
triply  redundant,  full-authority  digital  flight  control  system  for  primary  control 
and  a  triplex  analog  backup  system.  The  flight  qualification  and  validation  exper¬ 
ience  gained  on  the  F-8  DFBW  flight  program  is  described  in  reference  2.  The  com¬ 
mitment  to  remove  the  aircraft *s  mechanical  control  system  before  the  initial  flight 
test  forced  the  development  of  a  comprehensive  set  of  qualification  procedures, 
including  a  process  for  software  control  and  system  configuration  management.  This 
early  process,  which  stressed  rigorous  testing  procedures  and  formal  documentation, 
provided  the  basis  for  the  current  process. 

The  triply  redundant  primary  flight  control  system  of  the  F-8  DFBW  was  designed 
as  a  flexible  research  testbed,  and  has  allowed  many  flight  control  and  system 
research  experiments  to  be  investigated  in  flight.  In  over  6  years  of  active  flight 
testing  and  nearly  150  flights,  a  total  of  40  software  releases  have  been  qualified 
and  used  in  ground  and  flight  tests.  ’The  software  control  and  system  configuration 
management  system  has  been  used  successfully  to  track  over  500  discrepancy  reports 
and  to  process  more  than  320  program  changes  to  the  onboard  flight-critical  software 
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The  F-8  DFBW  aircraft  also  has  the  capability  to  use  a  remotely  augmented 
vehicle  (RAV)  flight  test  technique  for  investigating  advanced  control  law  con¬ 
cepts  in  a  cost-effective  manner.  The  RAV  concept  (ref.  3)  uses  a  ground-based, 
FORTRAN-Drogrammable  digital  computer  for  control  law  computations  and  up  and  down 
telemetry  links  to  allow  complete  closed- loop  control.  The  technique  was  designed 
to  provide  the  flexibility  and  versatility  necessary  to  investigate  advanced  or 
highly  speculative  control  concepts  in  flight.  The  onboard  flight  software  treats 
the  simplex  RAV  interface  and  mechanization  as  another  flight  control  mode  and  con¬ 
tains  the  necessary  validity  checks  required  to  maintain  overall  system  integrity. 

The  RAV  ground  computer  system  and  software  configurations  were  developed  and 
managed  using  the  same  process  as  was  used  for  the  onboard  software  and  flight  sys¬ 
tems.  The  system  testing  approach  was  modified  slightly  to  account  for  the  less 
critical  nature  of  the  RAV  ground  systems  and  software.  The  systems-wide  approach 
to  software  control  and  systems  configuration  management  made  the  accommodation  of 
the  additional  RAV  software  and  system  hardware  elements  a  relatively  easy  task. 

The  process  thus  demonstrated  its  inherent  flexibility  to  accommodate  and  manage 
complex  system  hardware  and  software  elements  that  might  be  added  to  an  advanced 
aircraft  flight  system  after  the  initial  development  phase. 


HiMAT  Program 

The  HiMAT  program  was  conceived  to  demonstrate  advanced  technology  concepts 
through  flight  tests  of  scaled  aircraft  using  a  remote  piloting  technique.  Advanced 
composite  structures,  aeroelastic  tailoring,  a  digital  integrated  propulsion  control 
system,  reduced  static  stability,  and  a  microprocessor-based  digital  fly-by-wire  con¬ 
trol  system  are  all  elements  of  the  HiMAT  program.  Closed-loop  primary  flight  con¬ 
trol  is  performed  from  a  ground-based  cockpit,  using  a  digital  computer  and  up  and 
down  telemetry  links.  A  backup  flight  control  system  for  emergency  operation  resides 
in  an  onboard  computer.  The  onboard  systems,  which  are  designed  to  provide  fail¬ 
safe  or  better  capabilities,  use  two  microcomputers,  dual  uplink  receiver/decoders, 
and  redundant  hydraulic  actuation  and  power  systems. 

The  HiMAT  system  development  and  flight  qualification  was  a  complex,  highly 
integrated  task  (ref.  4).  Four  independent  flight-control  digital  computers,  all 
with  different  software  programs,  were  required  to  meet  the  research  program  objec¬ 
tives,  The  two  ground-based  computers  were  programmed  in  FORTRAN,  and  the  two 
onboard  computers  were  programmed  in  assembly  language.  The  software  development 
facilities,  verification  tools,  and  ground  support  equipment  used  for  system  valida¬ 
tion  testing  were  specific  to  each  computer  system.  The  various  computer  hardware 
and  software  elements  were  quite  diverse,  yet  the  overall  flight  system  functions 
were  highly  integrated.  A  coordinated  and  consistent  software  and  system  develop¬ 
ment  process  was  essential  in  the  qualification  and  flight  test  activities. 

In  over  4  years  of  development  and  ground  and  flight  test  activities,  30  soft¬ 
ware  releases  were  generated  for  the  2  onboard  computers,  24  software  releases  for 
the  primary  ground  computer,  and  11  software  releases  for  the  other  ground  computer. 
Nearly  500  discrepancy  reports  were  written  and  resolved,  over  320  work  orders  were 
processed  for  flight  system  hardware  modifications,  and  over  480  program  changes 
were  incorporated  in  the  various  software  elements.  In  general,  the  HiMAT  pro^am 
used  the  outlined  discrepancy  reporting,  software  change,  and  system  verification/ 
validation  test  procedures  quite  rigorously.  However,  the  system  hardware  modifica¬ 
tion  process  was  tailored  to  respond  to  the  many  unique  and  dynamic  requirements  of 
the  HiMAT  flight  system  development.  In  particular,  many  of  the  system  hardware 
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changes  did  not  require  the  review  and  approval  of  the  conf .r guration  control  board; 
the  cognizant  systems  engineer  authorized  the  modifications  directly.  Any  major 
flight  control  system  hardware  modifications  and  those  of  an  integrated-systems 
nature  were  processed  according  to  the  established  procedures  for  overall  system 
configuration  management.  As  an  illustration  of  the  iterative  nature  of  an  advanced 
system  development  project^  the  system  development  history  of  the  HiMAT  program  is 
summarized  in  figure  4. 

The  software  control  and  system  configuration  management  process  proved  to  be  an 
effective  and  efficient  method  to  track,  document,  and  manage  this  advanced  aircraft 
system  development  activity.  The  capability  of  this  process  to  accurately  and  effi¬ 
ciently  manage  the  development  of  a  highly  integrated  flight  system  containing  multi¬ 
ple,  diverse  subsystems  with  an  overall  systems-wide  approach  was  again  demonstrated. 

CONCLUDING  REMARKS 


An  effective  software  control  and  system  configuration  management  process  for 
flight-critical  digital  control  systems  of  advanced  aircraft  has  been  described 
and  illustrated.  The  process  has  been  successfully  applied  to  a  number  of  programs 
involving  research  aircraft  and  remotely  piloted  research  vehicles  with  advanced 
flight  control  systems.  Key  factors  to  be  considered  in  the  development  of  a  soft¬ 
ware  control  and  system  configuration  management  process  that  works  include: 

1.  The  highly  complex  interactions  among  the  hardware,  software,  and  system 
elements  of  a  state-of-the-art  digital  flight  control  system  design  require  that  a 
systems-wide  approach  be  used  for  configuration  control  and  management. 

2.  Application  experience  has  shown  that  maintenance  of  separate  hardware  and 
software  configuration  control  procedures  is  ineffective  for  highly  integrated 
flight  systems  in  that  many  of  the  difficult  design,  development,  and  testing  issues 
involve  interactions  between  hardware  and  software  systems. 

3.  The  implementation  of  a  configuration  management  process  must  account  for 
the  fact  that  all  the  primary  system  development  phases  are  likely  to  require  itera¬ 
tive  development  over  the  lifespan  of  a  complex  flight  system. 

The  primary  purpose  of  the  software  control  and  system  configuration  management 
process  for  flight-critical  digital  control  systems  is  to  provide  a  method  for  effi¬ 
cient  system  development  and  a  process  for  assuring  safe  flight  operations.  The 
principal  elements  of  the  process  include:  (1)  procedures  for  reporting,  tracking, 
and  reconciling  all  system  hardware  and  software  discrepancies;  (2)  a  structured 
process  for  identifying,  reviewing,  and  implementing  system  hardware  and  software 
configuration  changes;  (3)  rigorous  system  verification  and  validation  test  proce¬ 
dures;  (4)  accurate  and  consistent  documentation  requirements;  and  (5)  an  active  and 
knowledgeable  configuration  control  board  to  review  and  approve  all  system  configu¬ 
ration  modifications. 

The  effectiveness  and  flexibility  of  this  software  control  and  system  configura¬ 
tion  management  process  has  been  demonstrated  in  use  on  several  advanced  flight  sys¬ 
tem  development  programs  of  varying  complexity  and  diverse  configurations. 
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APPENDIX  -  CONFIGURATION  MANAGEMENT  FORMS 


This  appendix  includes  examples  of  typical  forms  used  in  the  systems  configure 
tion  management  documentation  and  tracking  process:  Discrepancy  Report,  Configura 
tion  Change  Request,  Work  Order,  Program  Change,  and  System  Test  Report. 


DISCREPANCY  REPORT  (DR) 

-REPORT  GROUND-BASED  OR  AIRBORNE  PROBLEM 
WITH  HARDWARE.  SOFTWARE.  OR  ASSOCIATED  OPERATION. 

-SEE  PROCESS  SPECIFICATION  OD-7  FOR  DETAILS 


PART  A-AIRCRAFT/FACILITY  PORTION  OF  DR 


(9)  W3C«EfW<CT  -  Ul  ALL 


EAiLUHE  1ST  SUSfECT 


(14)  F1N04M6S  Of  OETAiUO  FAJLUKE  AMALTSIS  -  Am  CJut«s: 


T|10)  AIG/0Y/fA  I  ni)  PIT/QAHAS  1  112JFW  status  I  (13)  SfGHAIU.*,£/0»G/SITI 


i  1151  MO/OT/TA  hl8|  flT/Gf  mas  I  (17)  FW  STATUS  I  111)  SIGMATUAE/QAG/SIIE 


I  f  AJLUAE  CAUSE  fOUNO  -  0«a«4  UxtM)  A5«m 


(19)  COAAECTIVE  S  CLOSIMG  ACTIOMS: 


I  (701  fCM  S,  CCA'S  WO  S.  itt.  I  (211  mO/OT/TA  •  |721  ai/Of  HAS  *  (23)  fW  STARlS  I  (24)  S»GMATUA£/flAQ/SITE 


ACfT/FAClLTPr  CLOSEOUT  AOIOH  COAtfLfTI 


I  (23)  ACn/FAClurr  closeout  SMWATUAE: 


(21)  ACFT/FACJUn  CLOSEOUT  SlGMArUAE 


PART  B  -  □  SUB-ASSY  PORTION  OF  DR.  USE  FOR  HARDWARE  OR  SOFTWARE.  USE  1  PART  8  FOR  EACH  MAJOR  OR  LOWER  ASSY 


(35)  OISCAEPAMCT  -  Lfll  ALL 
FAILURE  1ST  SUSPECT 


I  (36)  MO/OT/TR  I  (37)  OP  MRS/CTC  *  (38)  FW  STATUS  I  (39)  SIGMATURE/OBG/SITE 


(40)  RNOtNGS  OF  OETAiUO  FAILURE  ANALYSIS  -  Lot  Itmlm^i  M  prmwily  liM: 


(41)  MO/OT/TR  I  (42)  QP  MRS/CTC  I  (43)  FW  STATUS  I  (44)  SIGNATURE/ORG/SITE 


FAILURE  CAUSE  FOUNO  -  OET AILS  USTED  A80VE 


I  (45)  CORRECTIVE  i  CLOSING  ACTIONS  NOT  PREVIOUSLY  LISTED: 


I  (46)  PCN  S.  OCR'S.  WO  S.  ttt  '  (A7)  MO/OT/TR  ‘  (46)  OP  HRS/CTC  *  (49)  FW  STATUS  *  (50)  StGNATUAE/ORG/SITE 


ITEM  CLOSEOUT  ACTION  COMPUTE 


I  (51)  ITEM  CLOSEOUT  SIGNATURE; 


I  (54)  ITEM  CLOSEOUT  SIGNATURE: 


CONFIGURATION  CHANGE 


CCR  NO. 

PROJECT 

INITIATOR 

ORGANIZATION 

DATE 

PROJECT  TEAM  REP. 

O.R.  NO.  (REF.) 

W.O.  NO.  (REF.) 

P.C.  NO.  (REF.) 

REQUEST; 

EVALUATION  AND  ASSESSMENT 

approve  Q 

DISAPPROVE  □ 

RETURN  FOR  ANALYSIS  □ 

FOR  RELEASE 

CCB  OFFICIAL 

DATE 

SiG - 

REMARKS 


DATE 


SIG 


DATE 


Work  Order 


{1}  DATE  OF  REQUEST: 


(2)  WORK  ORDER  NUMBER:  (3)  SUB-TASK: 


(4)  DATE  REQUIRED: 


(5)  STARTED: 


(6)  COMPLETED:  (7)  INSP: 


(8)  ORIGINATOR: 


TELEPHONE:  (9)  TO: 


(10)  PROJECT: 


(12)  APPROVALS:  (a) 


1}  ATTACHMENTS: 


If  YES  ,  lisf  «ach  attachment 
of  BOTTOM  of  WORK  ORDER 


date  signature 


DESCRIPTION  OF  WORK 


(15)  (16)  (17) 

DATE  TECH.  INSP. 


PROGRAM  CHANGE 

SOFTWARE  CHANGE  CONTROL 


REQUEST  NOTICE  1 


F  REQUEST.  DATE  DOCUMENTATION  UPDATED 


CHANGE  TO  REL 

DR  NO 

SPF.CIFICA^TION  REV,  NO 

description  of  change” 


— 

S/N 

ORIGINATOR/ORG. 

MODULES/SUB  ROUTINES  CHANGED  ' 

VERIFICATION  AND  VALIDATION  COMPLETE. 

SIG: - : — - - 

DATE; 

I  REASON  FOR  CHANGE 


REMARKS 


SYSTEM  TEST  REPORT 


TITLE 

NUMBER 

DATE 

ORIGINATOR/ORG 

RELEASE 

SYSTEM  CONFIGURATION 

OBJECTIVE 


CONT'O 
ON  PAGE 


TEST  SETUP 


SIG; 


SUMMARY  RESULTS 


DATE: 


CONT'O 
ON  PAGE 


SIG; 

CONCLUSIONS 


DATE; 


CONT'O 
ON  PAGE, 


SIG; 

DATE: 

CONT'O 

ON  PAGE  . 

RETEST  REQUIRED 

YES 

NO 

OR  ISSUED 

DATE 

NO. 

REMARKS 


W.O.  NO.  (REF.) 


PC  NO.  (REF) 


SIG; 


DATE; 


REFERENCES 
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Figure  3*  Documentation  flow  and  tracking  process* 
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BLOCK  II  CC^JTINUED  DEVELOPMENT  (CONTINUED) 


7.5  INITIAL  OPERATIONAL  TEST  AND  EVALUATION  ( lOT&E)  (OPTION) .  The 
contractor  shall  fabricate  and  deliver  four  Block  II  missiles  that 
replicate  the  production  configuration  of  the  missile.  The  contractor 
shall  provide  field  team  support  to  process  missiles  for  flight.  The 
contractor  shall  also  provide  support  of  flight  test  activity  at  WSMR 
Control  Center  and  at  the  launch  site.  The  Government  will  establish  and 
publish  restrictions  related  to  the  contractor’s  test  support.  The 
contractor's  support  shall  conform  to  all  of  these  restrictions.  The 
contractor  shall  also  respect  and  abide  by  directions  and  decisions  of  the 
operational  test  conductor.  When  requested,  the  contractor  shall  employ 
diagnostic  failure  analysis  and  reporting  techniques  for  analyzing  and 
reporting  hardware  and  software  failures  encountered  during  the  lOT&E. 

7.6  RANGE  SAFETY.  The  contractor  shall  support  preparation  of 
National  Range  Documentation,  and  comply  with  WSMR  Range  Safety  and  missile 
flight  test  planning  requirements.  Missile  flight  test  planning  shall 
include  support  for  preparation  of  Range  Safety  Data  to  meet  WSMR 
requirements.  Missile  destruct  procedures,  reaction  times,  and  debris 
footprints  shall  be  developed. 

7.7  SURFACE  DANGER  AREA.  Prior  to  test  firings  (including  sled 
testing),  an  interim  surface  danger  area,  defined  to  a  one-in-one  million 
escapement  probability  criteria,  shall  be  constructed  utilizing  Army  TACMS 
Block  I  methodology.  Both  normal  and  malfunctioning  modes,  assumptions 
made,  and  a  description  of  the  system  behavior  for  each  malfunction 
possible  and  probability  of  occurrence  shall  be  included.  The  final 
surface  danger  area  assessment  shall  be  derived  from  the  data  used  for  the 
interim  footprint,  flight  data,  and  data  derived  from  simulations  and 
flight  characteristics  with  the  integration  of  the  BAT  submunition.  The 
final  surface  danger  area  shall  also  include  a  one-in-one-hundred-thousand 
escapement  probability  footprint.  The  interim  and  final  surface  danger 
areas  shall  be  included  as  an  appendix  to  the  SAR. 

8.0  CONFIGURATION  MANAGEMENT. 

8.1  FUNCTIONAL  BASELINE  (FBL),  The  FBL  for  the  Army 

TACMS  Block  II  continued  development  shall  be  the  Army  TACMS  system 
specification,  MIS-38578  Addendum  II. 

8.2  REQUESTS  FOR  OFFICIAL  MILITARY  NOMENCLATURE.  The  contractor  shall 
prepare  and  submit  to  the  procuring  activity  requests  for  nomenclature  for 
major  end  items  and  their  principle  components  which  are  to  be  type 
classified. 

8.3  CHANGES  TO  GOVERNMENT  CONTROLLED  DOCUMENTATION.  Changes  to 
documentation  under  Government  control  shall  be  incorporated  only  after 
Government  approval  of  Engineering  Change  Proposals  (ECPs).  The  contractor 
shall  assign  ECP  numbers  obtained  from  the  Government.  Notices  of  Revision 
(NORs)  shall  be  prepared  for  each  affected  drawing  or  specification  and 
shall  be  included  as  an  integral  part  of  the  ECP. 

8.4  METRICS.  All  data  and  documents  developed  under  this  SOW  shall 
utilize  metric  units. 

8.5  DOCUMENTATION  STORAGE  AND  CONTROL.  The  contractor  shall  have 
custodianship  of  all  technical  documentation  generated  and/or  maintained 
under  this  SOW  and  shall  utilize  a  central  fireproof  repository  appropriate 
for  accommodating  all  original  and  master  documentation  and  computer  tapes 
or  other  media.  The  contractor  shall  establish  and  maintain  control  access 
to  these  data  LAW  the  documentation  storage  and  control  portion  of  the  CMP. 
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BLOCK  II  CCNTINUZD  DEVELOPMENT  (CONTINUED) 

8  6  DELIVERY  OF  DRAWINGS.  Unciassif ied/uniimited  rights  data  to  be 

submitted  t:  the  Government  repository  shall  be  in  raster  image  fo^t(on 
maenetic  '*oe  f9-track  1600/6250  bits  per  inch  [BPI]  fully  compatible  with 
?^C0M  DIGITAL  STORAGE  AND  RETRIEVAL  ENGINEERING  DATA  SYSTEM  [DSREDS], 
-omoression  is  Comite’  Consultatif  International  de  Telegraphique  et 
Teleohoricue  (English:  International  Consultative  Committee  on  Telegraphy 
and  Teleprionv]  [CCITT],  group-4,  non-wrap  format,  document  identifier 
record  is  soecified  in  the  attachment  to  Document  Summary  List  [DSL], 
document  tvte  codes  same  as  for  aperture  cards  )  or  microfi^  aperture 
format  (coinatible  with  and  lAW  DESREDS 

originals,  as  sets  in  numerical  sequence).  Classified/l^ted 

shall  be  delivered  in  microfilm  aperture  card  format  only.  Each  shall  be 

marked  appropriately  to  identify  the  data  contained  within. 

9.0  PRODUCT  ASSURANCE. 

9.1  MAJOR  NON-CONFORMANCES.  All  critical  and  major  non-conformances 
shall  be  nrocessed  through  formal  materiel  review  board  procedures.  The 
p^cirlng^^tlvHy  reserves  the  right  of  approval  for  material  review  board 
determinations  related  to  critical  and  major  non-conformances. 

9.2  PROHIBITED  PARTS,  MATER TELS,  AND  PROCESSES  (PMPs).  A  listing  of 
prohibited  PMPs  is  found  at  attachment  07. 

9.3  hardware /SOFTWARE  VALIDATION.  All  special  inspection  equipment 

(SIE)  and  soecial  test  equipment  (STE)  and  their  associated  software  shall 
be  validated  by  the  procuring  activity  prior  to  use  for  acceptance  or 
hardware . 

10.0  INTEGRATED  LOGISTICS  SUPPORT  (ILS). 

10 . 1  PROGRAM  REQUIRQffiNTS . 

a.  The  contractor  shall  implement  the  Integrated  Support  Approach 
that  is  a  part  of  this  contract.  The  contractor  shall  conduct  a  logistics 
demonstration. 

b.  The  Government  shall  periodically  review  and/or  audit 
contractor  adherence  to  integrated  logistics  support  processes  established 
by  the  contractor  for  the  performance  of  the  Block  II  program.  Depending 
on  the  results  of  these  reviews,  the  Government  may  issue  recommendations 
for  process  improvement  (CIOs)  or  provide  NODe.  The  contractor  shal 
responsible  for  developing  and  implementing  corrective  action  plans  to 
return  contractor  processes  to  control. 

10.2  SYSTEM  SUPPORT  PACKAGE  (SSP)  FOR  DEMONSTRATIONS  AOT  TESTING.  The 
contractor  shall  assemble  and  deliver  all  items /equipment  identified  on  the 
SSPCL  and  deliver  to  the  test  sites  30  days  prior  to  the  scheduled  start 
date  of  each  test. 

10.3  LOGISTICS  SUPPORT  AHALYSIS\LOGISTICS  SUPPORT  ANALYSIS  RECORD 
(L^/LSAR).  The  contractor  shall  perform  LSA  during  the 

integration  of  the  BAT  submunition,  'pie  LSA  performed  on  TAC^  Block 

II  shall  be  consistent  with  the  existing  Army  TAC^  Block  lA  program.  LSA 
shall  also  be  performed  on  modifications  to  the  M270  lavpcher  and 
training  and  support  equipment  to  support  Block  II  application,  and  sha 
be  consistent  with  existing  M270  launcher  data  base. 

10.4  BLOCK  II  DOCUMENTATION /STORAGE /ACCESS  REQUIREMENTS. 
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SARD-PP 


MEMORANDUM  FOR  SEE  DISTRIBUTION 

SUBJECT:  Army  Policy  on  Delivery  of  Contract  Data 
Items 


The  Army  is  committed  to  acquisition  excellence 
through  acquisition  reform  and  improvement.  To  improve 
productivity  and  move  toward  a  paperless  environment,  the 
following  is  effective  immediately  for  all  Army  components 
where  possible  for  each  data  item  to  be  delivered  under  a 
contract,  only  one  copy  shall  be  specified  with  a  single 
delivery  point  and  a  single  destination  point.  It  is 
preferred  and  strongly  encouraged  that  data  items  be 
delivered  using  electronic  media. 


Gilbert  F.  Decker 
Army  Acquisition  Executive 


DISTRIBUTION: 

ADMINISTRATIVE  ASSISTANT,  ATTN:  SAAA/JDSS-W 
DIRECTOR  OF  INFORMATION  SYSTEMS  FOR  COMMAND,  CONTROL, 
COMMUNICATIONS  AND  COMPUTERS,  ATTN:  SAIS-ZA/SAIS-ZB/ 
SAIS-SP/SAIS-AE 
CHIEF  OF  ENGINEERS 
CHIEF,  NATIONAL  GUARD  BUREAU 
THE  SURGEON  GENERAL 

COMMANDERS 

U.S.  ARMY  TRAINING  AND  DOCTRINE  COMMAND, 

ATTN:  ATCD-2A/ATCD-RM 

U.S.  ARMY  MATERIEL  COMMAND,  ATTN:  AMCCG/AMCDCG/AMCAM/ 
AMCRD/ AMCRM/ AMCAQ/ AMC I  CP 

U.S.  ARMY  INFORMATION  SYSTEMS  COMMAND,  ATTN:  ASCG/ASGS 

U.S.  ARMY  INTELLIGENCE  AND  SECURITY  COMMAND 

MILITARY  TRAFFIC  MANAGEMENT  COMMAND 

U.S.  ARMY  CRIMINAL  INVESTIGATION  COMMAND 

U.S.  ARMY  MILITARY  DISTRICT  WASHINGTON 

U.S.  ARMY  OPERATIONAL  TEST  AND  EVALUATION  COMMAND 
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COMMANDERS  (Con't); 

U.S.  ARMY  SPACE  AND  STRATEGIC  DEFENSE  COMMAND  ^ 

U.S.  ARMY  AVIATION  AND  TROOP  SYSTEMS  COMMAND 
U.S.  ARMY  COMMUNICATIONS-ELECTRONICS  COMMAND 
U.S.  ARMY  MISSILE  COMMAND 
U.S.  ARMY  TANK  AUTOMOTIVE  COMMAND 

U.S.  ARMY  CHEMICAL  BIOLOGICAL  DEFENSE  AGENCY  COMMAND 
U.S.  ARMY  TEST  AND  EVALUATION  COMMAND 
U.S.  ARMY  SIMULATION,  TRAINING  AND  INSTRUMENTATION 
COMMAND 

U.S.  ARMY  RESEARCH  LABORATORY 
U.S.  ARMY  INSDUSTRIAL  OPERATIONS  COMMAND 
U.S.  ARMY  MEDICAL  RESEARCH,  DEVELOPMENT,  ACQUISITION 
AND  LOGISTICS  COMMAND  (PROVISIONAL) 

U.S.  ARMY  EUROPE 
U.S.  ARMY  PACIFIC 
EIGHTH  U.S.  ARMY 
U.S.  ARMY  SOUTH 

PROGRAM  EXECUTIVE  OFFICERS 
AVIATION 

ARMORED  SYSTEMS  MODERNIZATION 

C(»IMAND  AND  CONTROL  SYSTEMS 

COMMUNICATIONS  SYSTEMS 

FIELD  ARTILLERY  SYSTEMS 

INTELLIGENCE  AND  ELECTRONIC  WARFARE 

STANDARD  ARMY  MANAGEMENT  INFORMATION  SYSTEMS 

TACTICAL  MISSILES 

TACTICAL  WHEELED  VEHICLES 

MISSILE  DEFENSE 

DIRECTOR,  ARMY  ACQUISITION  EXECUTIVE  SUPPORT  AGENCY 
JOINT  PROGRAM  OFFICE,  BIOLOGICAL  DEFENSE 
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SPACE  SHUTTLE  ONBOARD  SOFTWARE 
PROGRAM  MANAGEMENT 

AND 

CONFIGURATION  CONTROL 

PROCESS 


1.  SPACE  SHUTTLE  ORBITER  AVIONICS  SOFTWARE 


1.1  INTRODUCTION 

The  purpose  of  the  Space  Shuttle  Orbiter  Avionics  software  is  to  provide  the  means  of  bringing  the  essential 
but  diverse  portions  of  the  Orbiter  together  into  a  system  which  responds  to  the  demands  of  its  users.  The 
software  development  process  is  managed  to  ensure  that  the  delivered  product  provides  the  required  func¬ 
tions  and  ser\'ices  and  is  only  changed  under  controlled  conditions.  This  plan  provides  an  overview  of  the 
software  development  process  and  the  management  approach  which  the  IBM  Corporation  uses  to  assure 
that  quality  software  products  are  provided  to  NASA  according  to  schedule. 

1.1.1  Purpose 

This  document  provides  IBM's  management  approach  for  the  development  of  the  Space  Shuttle  Orbiter 
Avionics  software  to  support  the  Operational  Flight  phase.  The  software  development  process  as  described 
in  this  document  includes  software  maintenance.  All  processes  are  identical  for  development  and  mainte¬ 
nance  except  for  authorizing  document  and  approval  processes. 

1.1.2  Scope 

This  process  is  applicable  to  the  development,  verification,  and  certification  of  the  Onboard  Space  Shuttle 
Orbiter  Aviomes  software. 


1.2  RESPONSIBILITIES 

The  development  and  maintenance  of  the  Space  Shuttle  Orbiter  Avionics  software  is  the  responsibility  of 
IBM  in  response  to  NASA  supplied  requirements.  For  functional  capability  development,  IBM  responds  to 
software  Change  Requests  (CRs)  approved  by  the  Shuttle  Avionics  Software  Control  Board  (SASCB)  of  the 
NASA  Project  Office  (PO).  IBM  also  has  the  responsibility  for  the  development  and  maintenance  of  Flight 
Software  Application  Tools  (FSWAT).  FSWAT  is  the  set  of  software  tools  that  supports  the  development 
and  reconfiguration  of  the  Flight  Software.  Changes  to  the  FSWAT  are.  governed  by  Support  Software 
Change  Requests  (SSCRs)  and  Support  Software  Discrepancy  Reports  (SSDRs).  Both  FSW  and  FSWAT 
changes  are  packaged  into  Operational  Increments  (OIs)  and  implemented  and  tested  by  IBM  in  the  Soft¬ 
ware  Development  Facility  (SDF).  It  is  the  responsibility  of  IBM  to  completely  test  each  of  these  incre¬ 
ments  in  preparation  for  subsequent  reconfiguration  prior  to  being  used  to  support  STS  flights.  Formal 
rc%’iew  and  acceptance  of  the  implementation  and  testing  of  each  01  is  the  responsibility  of  the  NASA 
Spacecraft  Software  Division  (SSD).  IBM  participates  in  the  configuration  inspection  (Cl)  chaired  by 
NASA/SSD.  Cl  is  held  for  each  OI  following  completion  of  the  independent  verification  phase  of  the  devel¬ 
opment 

For  flight  to  flight  reconfigurations,  IBM  is  responsible  for  the  certification  of  the  PASS  FSW.  IBM  inde¬ 
pendently  produces  a  reference  Mass  Memory'’  and  compares  the  final  products  as  well  as  some  intermediate 
products,  to  Space  Transportation  System  Operations  Contract's  (STSOC's)  Mass  .Memory.  Miscompares 
are  analyzed  and  corrected  as  required.  Furthermore,  formal  testing  is  performed  on  the  flight  Mass  .Memory 
to  verify  the  flight  readiness  before  IBM  signs  the  Flight  Readiness  Statement. 

Certification  is  only  applicable  to  PASS  Reconfiguration  buUds  of  deliverable  products  specified  by  the  Mass 
Memory'  Integration  Plan  (\IIP)  as  delimited  by  the  FRONTROOM  BACKROOM  INTERFACE 
CONTROL  DOCUMENT  (ICD). 
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1.3  PROJECT  MANAGEMENT 


1.3.1  Project  Manager 

'I'he  project  manager  is  responsible  for  ensuring  that  the  software  being  designed,  de\’eloped  and  tested  for 
the  Space  Shuttle  Orbitcr  Avionics  meets  the  requirements  and  objectives  established  b)'  V.A.SA.  The 
project  manager  also  ensures  adherence  to  processes,  procedures,  -md  confrgiaTaUon  management.  Fuii  com¬ 
pliance  with  these  items  is  indicated  with  the  project  manager's  signing  of  the  Cc.mficaUon  of  Flight  Read¬ 
iness  (COFR)  for  each  shuttle  mission.  To  achieve  these  objectives  the  project  manager  has  organized  a 
project-oriented  organization  (see  Figure  1-1  on  page  1-3).  This  organization  ensures  that  maaiagernent  has 
access  to  and  control  of  all  resources  necessary  to  meet  schedules  and  performance  objectives.  The  Softaa^e 
Quality  Assurance  (SQA)  organization  is  independent  of  the  OBS  project  and  management. 

1.3.2  Onboard  Space  Shuttle 

The  project  manager  is  responsible  for  the  development  of  all  Primary  Avionics  Software  System  (PASS) 
capabilities,  certification  of  all  flight  systems,  and  the  development  of  application  support  software  systems 
used  in  the  preparation  of  the  flight  systems.  The  maintenance  of  project  baselines  and  schedules  is  accom¬ 
plished  through  a  project-wide  Backroom  Baseline  Control  Board  (BBCB).  The  chair  person  of  the  BBCB 
is  a  staff  function  reporting  directly  to  the  Project  Coordination  Manager.  Members  include  second  level 
management  and  key  staff  personnel  from  all  appropriate  areas.  The  charter  of  the  BBCB  is  threefold: 

•  Define,  negotiate  and  baseline  project-wide  development,  build,  test  and  delivery'  schedules 

•  Control  and  baseline  flight  software  change  baselines  (Change  Requests  and  Discrepancy  Reports) 

•  Coordinate  interproject  technical  issues 

The  organizational  structure  involves  six  major  areas.  The  areas  correspond  to  the  following  general  activ¬ 
ities  and  are  described  in  detail  in  the  follow'ing  paragraphs: 

•  Development  and  maintenance  of  new  and  existing  flight  software  capabilities 

•  Verification  of  flight  software  capabilities 

•  Flight  operations  support 

•  Flight  reconfiguration  certification 

•  Development  and  test  of  support  software  systems 

•  System  build 

1. 3.2.1  Avionics  Software  Development 

The  Avionics  Software  Development  organization  is  responsible  for  the  development  of  enhancements  and 
maintenance  to  flight  software  applications  and  operating  system  capabilities.  These  software  enhancements 
are  defined  by  the  NASA  PO  Shuttle  Avionics  Software  Control  Board  (SASCB)  via  CRs.  In  collaboration 
with  NASA  PO  and  SSD,  these  changes  are  packaged  into  software  systems  called  OIs  and  nominally  devel¬ 
oped  on  six  month  centers.  In  general,  a  single  01  will  support  multiple  STS  flights  with  software  releases 
called  OF's. 

In  addition  to  development,  the  organization  is  also  responsible  for  software  system  architecture  and  memory- 
analysis. 
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•  Certification 
Of  Flight 
Reconfiguration 


•  FSW  Sc  FSWAT 
System  Build 
And  Integration 


•  Software 
Development 
And  Test 
Support  Systems 


Figure  1-1.  Onboard  Space  Shuttle  Project  Organization 
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1.3. 2. 2  Avionics  Software  Engineering  and  Verification 

'fhe  verification  organization  is  responsible  for  the  test  of  enhancements  to  the  flight  software  and  operating 
system.  Each  01  is  tested  and  made  available  for  reconfiguration,  i.e.,  the  application  of  mission  and 
payload  specific  data. 

I'hc  Engineering  organization  is  responsible  for  re\-ievving  all  proposed  requirements  changes  to  the  flight 
software  to  ensure  that  the  software  can  perform  properly  (Central  Processing  Unit  (CF^U)  timing  measure' 
ments,  etc.),  and  meet  desired  flight  objectives. 

1.3. 2. 3  Test  and  Operations 

The  Test  and  Operations  (T&O)  organization  supports  installation  and  mamtcnancc  of  delivered  systems  m 
the  users  sites  which  include,  the  orbitcr  vehicle  and  test  facilities  at  the  Kennedy  Space  Center  (KSC),  the 
Shuttle  Mission  Simulator  in  Houston,  the  Shuttle  Avionics  Integration  Laboratory’  in  Houston,  the  KSC 
Automated  Test  Set,  the  Cargo  Integration  and  Test  Equipment  at  KSC,  the  JSC  Avionics  Engineering  Lab- 
orator>'  (JAEL),  and  other  sites  as  required. 

1.3. 2. 4  Flight  Software  Application  Tools  (FSWAT) 

The  Flight  Software  Application  Tools  organization  is  responsible  for  building  software  used  for  the  develop¬ 
ment,  reconfiguration,  and  test  of  PASS  Flight  Software.  The  types  of  software  produced  include:  flight 
simulation,  preprocessors,  post-processors,  build  and  data  analysis  tools.  ESWAT  is  also  responsible  for 
maintaining  the  software  configuration  management  data  bases.  The  major  functions  performed  by  FSWAT 
include:  writing  requirements,  generating  design  and  code,  performing  unit  test  and  verification,  and  gener¬ 
ating  and  publishing  User's  Guides  and  requirements  documents  for  the  produced  software. 

1.3. 2.5  System  Build 

The  System  Build  organization  is  responsible  for  building  FSW  and  FSWAT  systems  from  source.  It  also 
performs  all  the  flight-to -flight  Reconfiguration  Certification  builds.  This  group  assures  that  ail  developed 
software  changes  are  put  on  systems  in  a  controlled  fashion.  Other  functions  performed  by  this  group 
include  building  integrated  Mass  Memories  and  generating  software  deliverables. 

1. 3.2.6  Contracts 

The  contracts  department  is  primarily  responsible  for  cost  'manpower  monitoring,  analysis  and  reporting.  In 
addition,  the  department  is  also  responsible  for  subcontract  monitoring  and  GFE  and  IB.M  property  admin¬ 
istration  and  control. 

1.3. 2.7  Flight  Certification 

The  Certification  task  is  performed  in  parallel  with  but  not  in  line  to  the  STSOC  reconfiguration  process. 
IBM  independently  builds  a  Mass  Memory.  This  Mass  Memor>’  is  compared  with  the  one  built  by  STSOC 
and  the  results  are  reported  to  SSD.  The  STSOC  .Mass  .Memor>-  is  then  copied  over  the  IBM  build  .Mass 
Mcmor\'  so  that  independent  testing  can  be  performed  on  the  Flight  .Mass  Memor\‘.  Results  of  this  testing 
is  reported  to  SSD  through  a  formal  Certification  Test  Review  (CTRj.  IB.M  signs  the  Flight  Readiness 
Statement  to  denote  that  the  PASS  FSW  is  certified. 
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1.3.3  Software  Quality  Assurance  (SQA) 

The  independent  SQA  organization  has  the  responsibility  for  assuring  that  all  software  development  phases 
of  the  contract  are  conducted  in  accordance  with  the  requirements  and  standards  specified  in  the  contract 
and  any  applicable  IBM  imposed  requirements.  The  SQA  personnel  are  responsible  for  assunng  the  fol- 
lowing: 

1.  Preparation  of  Software  Quality  Assurance  Plans  (SQAP) 

2.  Direction  of  program  quality  assurance  efforts 

3.  Coordination  with  DCASPRO,  customer  and  subcontractor  representatives  on  quality  matters 

4.  Auditing  the  accomplishment  of  the  SQAP  requirements. 


1.4  MANAGEMENT  CONTROLS 


To  insure  management  control  of  flight  and  support  software  development  and  certification  activities  the 
Onboard  Space  Shuttle  project  utilizes  the  foUowing  mechanisms; 

•  A  series  of  Internal  IBM  control  boards  with  direct  interfaces  to  corresponding  NASA  control  boards 
(see  Figure  1-2  on  page  1-6) 

•  A  rigorously  controlled  Configuration  Management  Data  Base  (CMDB)  containing  release  contents 
(Requirements  changes,  discrepancy  corrections)  under  the  control  of  the  IBM  board  chairmen  (see 
Figure  1-3  on  page  1-7) 

•  A  series  of  weekly  and  bi-monthly  status  and  policy  meeting  with  various  levels  of  IBM  and 
NASA/Spacecraft  Software  Division  management 

•  Weekly  and  bi-monthly  publication  of  baselines,  project  and  detailed  schedules  and  development  plans 
including  the  I B.M  internal  BBCB  datapack  which  provides  a  comprehensive  project  summary. 
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Figure  1-2.  IB.\I  Control  Boards 
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6.  CONFIGURATION  MANAGEMENT 


Configuration  management  is  the  process  of  authorising  and  documenting  ever}'  modification  to  each 
product  end  item.  This  is  accomplished  through  the  use  of  two  procedural  concepts:  configuration  control 
and  configuration  management  tools. 


6.1  CONFIGURATION  CONTROL 


Configuration  control  is  the  establishment  of  technical  control  points  called  baselines  and  the  ssstcmatic 
e\alualK)n,  coordination,  and  disposition  of  all  proposed  changes  to  these  baselines.  The  manauement  of 
configuration  control  within  IB.M  is  the  primars'  responsibility  of  the  Backroom  Baseline  Control  Board 
(BBCB)  to  coordinate  the  overall  project  configuration  elements  so  that  each  activity  element  is  efficiently 
integrated  with  the  rest  of  the  project. 

6.1.1  Project  Configurations 

The  BBl.B  con\ cnes  regularly  with  management  and  key  staff  personnel  from  all  appropriate  areas  to 
compare  actual  status  and  scheduled  milestones.  The  following  baselines  are  reviewed  and  revised  or  re¬ 
scheduled  as  necessary  by  the  BBCB  in  order  to  support  both  the  other  project  actuities  and  product  com¬ 
mitments: 

a.  Active  flight  software  systems  available 

b.  Active  simulator  systems  available 

c.  Flight  software  build  and  release  schedules 

d.  Flight  software  build  and  release  contents 

e.  Simulator  software  build  and  release  schedules 
f  Simulator  software  build  and  release  contents 

g.  Certification  build  and  compare  schedules 

h.  Support  hardware  configurations 

i.  Computer  time  schedules 

j.  Configuration  management  data  base  (CMDB)  contents 

k.  Receipt  dates  for  government  and  STSOC  furnished  input  data  items 

l.  Commitments  to  the  customer  (NASA) 

I  he  flight  software  and  the  Flight  Softw^are  Application  Tools  (FSWAT)  configuration  control  is  delegated 
to  four  sub-boards  which  report  to  the  BBCB.  Those  boards  are;  the  Primary  Avionics  Software  System 
(PASS)  Discrepancy  Report  (DR)  Review  Board,  the  Requirements  Review  Board  (RRB)  which  maintains 
requirements  Change  Request  (CR)  configuration  control  for  the  PASS,  the  Support  Software  Review- 
Board  (SSRB)  which  maintains  CR  configuration  control  for  FSWAT,  and  the  Support  Software  DR  Board 
(SSDRB). 

6.1.2  Flight  Software 

The  PASS  DR  Board  is  charged  with  the  responsibility  of  reviewing  and  reporting  on  the  results  of  each 
suspected  flight  sottware  error  identified.  Recommendations  are  made  to  NASA  as  to  the  resolution  of  each 
such  problem.  NASA  is  then  responsible  lor  approving  or  disapproving  the  recommended  action  for  each 
discrepancy.  In  cases  where  changes  in  P.ASS  requirements  are  invoh'cd.  the  RRB  is  the  reviewing  and 
reporting  hoard.  .Modifications  to  the  CR  baseline  are  determined  by  the  NASA  control  board  appro\als  of 
the  new  requirements.  Maintenance  of  the  PASS  CR  baseline  within  IB.M  is  the  responsibility  of  the  RRB. 
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6.1.3  Flight  Software  Application  Tools  (FSV/AT) 


The  Support  Software  Requirements  Control  Board  (SSRB)  within  the  FSWAT  organization  is  responsible 
for  FSW'AT  requirements  and  maintenance.  These  responsibilities  are  described  in  Sections  3.2.2  and  3.6. 
respectively. 


6.2  CONFIGURATION  CONTROL  DOCUMENTS 

Changes  to  the  PASS  or  FSWAT  software  are  documented  as  either  DRs  or  CRs.  CRs  are  initiated  when  a 
program  requirement  has  changed.  A  DR  is  initiated  when  known  or  suspected  errors  arc  detected  in  the 
software  requirements,  design,  or  code.  DRs  and  CRs  may  be  originated  by  NASA,  IB.M,  or  any  using 
agency  of  IB.M  end  items. 

Each  DR  or  CR  is  logged  into  the  CMDB  and  forwarded  to  the  line  organizations  of  software  development 
and  software  verification  for  assessment,  'fheir  assessment  is  reviewed  by  the  appropriate  CR  or  DR  review 
board  where  oasic  recommendations  of  disposition  and  implementation  are  made.  The  review  board  deter¬ 
mines  the  recommendation  to  be  presented  to  NASA.  I'he  final  approval  is  received  via  the  NASA  control 
boards.  Subsequent  handling  of  the  report  or  change  is  done  by  the  line  organizations  to  perform  modifica¬ 
tions  in  the  software  as  required  after  which  the  DR  or  CR  is  closed.  I'hc  status  of  the  report  or  request 
during  the  cycle  is  maintained  in  the  CMDB. 

6.2.1  Change  Requests 

A  CR  is  initiated  when  a  change  to  a  baseline  requirement  is  proposed  or  a  discrepancy  other  than  an  imple¬ 
mentation  error  has  occurred.  Requests  may  be  originated  by  NASA,  Rockwell,  IBM,  or  other  contractors. 
Information  about  the  change  includes  a  description,  justification,  computer  program  end  item  baseline 
impacted  and  affected  software  areas.  Agencies  external  to  IB.M  originating  CRs  submit  them  to  NASA. 
IBM  originated  CRs  go  to  the  RRB  and  then  to  NASA  Spacecraft  Software  Division  (SSD).  The  change  is 
assigned  a  control  number  by  NASA. 

Once  an  IBM  originated  CR  has  received  RRB  approval  it  goes  to  the  SSD  Change  Control  Board  (CCB) 
with  other  non-IBM  generated  CRs.  A  CCB  approved  CR  must  then  be  approved  by  the  SASCB  before 
IBM  is  directed  to  implement  it.  At  that  time  the  CR  is  scheduled  in  the  C.MDB  and  baselined  for  a  spe¬ 
cific  software  release  system.  The  CMDB  then  series  as  the  baseline  for  each  software  system.  Updates  to 
the  software  can  only  be  perfonmed  for  approved  change  authorities  as  designated  in  the  C.MDB. 

The  CMDB  is  the  baseline  against  which  independent  verification  builds  their  test  plans.  /Ml  change  author¬ 
ities  are  specifically  verified. 

6.2.2  Discrepancy  Reports 

.Any  user  at  any  test  facility  or  operational  site  in  which  the  P.ASS  software  or  the  FSWAT  software  is  in  use 
may  originate  a  DR  to  identify  a  known  or  suspected  software  error. 

Inibrmation  about  the  error  is  recorded  by  the  originator  and  includes  identification  of  the  suspected  module 
and  the  system  being  used,  conditions  at  time  of  error,  and  a  specific  description  of  the  error.  .Any  agency 
which  uncovers  an  error  supplies  the  information  about  the  error  on  a  DR  form  with  a  unique  control 
number  which  identifies  the  discrepancy  in  subsequent  activity.  IBM  sends  a  copy  of  the  discrepancy  to 
N.AS.A  for  review  and  enters  it  into  the  CMDB.  .An  analysis  sheet  containing  a  full  discussion  of  the  anal¬ 
ysis  and  the  effects  of  the  problem  is  added  to  the  DR  once  resolved.  IB.M  maintains  these  documents  for 
future  reference.  Once  IBM  and  NASA  agree  that  a  DR  should  be  resolved  via  a  software  change,  that 
change  is  scheduled  in  the  CMDB  for  an  appropriate  release.  The  CMDB  then  scr\-cs  as  the  baseline  for 
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each  software  system.  Lpdates  to  the  software  can  only  be  performed  for  approved  chan'^c  authonties  as 
designated  in  the  C.MDB. 

The  CMDB  is  the  baseline  against  which  independent  verification  builds  their  test  plans.  All  chance  author- 
ities  are  specifically  \'erified.  *  “ 


6.3  CONFIGURATION  MANAGEMENT  TOOLS 


6.3.1  Configuration  Management  Data  Base  (CMDB) 

Ihc  C.MDB  is  the  repository  for  the  control  and  descriptive  information  relating  to  project  CRs  or  DRs. 
Ihc  designation  "change  request"  includes  any  and  all  control  instruments  (e.g.,  CRs,  SSCRs)  authori/ins 
changes  to  project  requirements  or  baseline  items.  DRs  authorize  changes  when  project  software  systems  or 
procedures  do  not  conform  to  requirements.  The  C.MDB  provides  the  mechanism  for  management, 
tracking,  and  control  of  flight  software,  support  software,  and  test  software  in  both  the  Shuttle  Software 
development  and  production  environment.  Build  programs  which  create  or  modify  permanent  (baseline) 
segments  in  system  data  bases  (e.g.,  Development  System  Base  (DSB)  and  mission  data  base)  do  so  under 
the  authonty  of  approved  CRs  and  DRs  as  found  in  the  C.MDB.  The  CMDB  is  maintained  by  the  config¬ 
uration  management  and  control  functions  as  the  centralized  storage  facility  for  all  relevant  change  control 
data.  It  sers  cs  as  the  source  of  status  query'  responses  and  status  report  generation.  In  addition,  it  maintains 
a  limited  cumulativ'e  change  histor>’  of  other  system  data  bases. 

6.3.2  Member  Name  Implementation  Data  Base  (MNIDB) 

Ihc  Implementation  Data  Base  (IDB)  represents  a  central  repository  for  storing  FSW  and  FSWAT  support 
software  data  related  to  an  associated  DSB  or  .Mission  System  Base  (.MSB),  the  KEPT  hbraryy  or  a  mission 
data  base  (.MDB).  An  IDB  associated  with  a  DSB  or  .MSB  contains  manually  supplied  PASS  and  FSWAT 
information  referred  to  as  descriptive  data.  This  data  represents  information  supplied  by  designers,  devel¬ 
opers,  and  verifiers  and  contains  information  such  as  program  ownership  and  processing  instructions,  per¬ 
formance  catena,  and, or  hidden  cross  references  in  the  software.  Both  DSB  .MSB  and  IDBs  contain  FWS 
and  Its  support  software  descriptor  data  for  all  combinations  of  features  that  they  arc  required  to  support. 
.'Vn  IDB  associated  with  an  .MDB  initially  contains  only  the  descriptor  data  for  that  subset  of  .MSB  IDB 
names  required  in  support  of  the  mission  being  budt.  This  includes  all  member  names  unaffected  by  features 
as  well  as  those  member  names  affected  by  the  selected  feature  set  associated  with  the  mission.  Subsequent 
ata  is  added  to  an  IDB  in  an  .MDB  as  a  result  of  mission  reconfiguration  activities  when,  for  example,  load 
module  and  M.MU  addresses  are  installed  following  linkage  editor  and  .MMU  build  activities,  or  when 
IWoad  values  are  installed  for  specific  FSW  variables  following  e.xecution  of  the  1-Load  Preprocessor. 
KEPT  IDBs  contain,  instead  of  normal  baseline  segments,  pool  elements  that  have  previously  be.en  build 
into  one  or  more  .MDBs  or  System  Bases  and  arc  awaiting  future  use  in  additional  .MDBs  or  SBs. 

.Ml  IDB  IS  organized  to  proside  a  set  of  information  related  to  a  basic  unit  of  FSW  and  or  support  software 
data  identifiable  by  its  member  name. 

The  data  related  to  member  names  are  stored  in  a  member  name  implementation  data  base  (.MNIDB).  The 

-MNIDB  contains  desenptor  data  for  member  names  that  are  such  thinus  as  programs,  procedures  and 
macros. 
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6.3.3  Build  Control  List  Data  Base 


The  Build  Control  List  (BCL)  data  base  is  used  during  all  system  builds  (DSB,  .MDB)  as  a  depositor)'  for 
build  progress  status  data  as  well  as  to  control  the  sequencing  and  acti\itics  performed  in  builds.  'Fhe  BCL 
data  base  provides  for  individual  BCLs  (one  per  build)  to  be  created,  managed,  used,  and  removed  as  the 
build  is  planned,  performed,  and  reported  to  the  C\!DB.  Each  BCL  in  the  BCL  data  base  is  separated  from 
other  BCLs  both  physically  and  logically  so  that  builds  do  not  interfere  with  each  other.  As  a  part  of  build 
preparation  for  a  s\  stem,  a  BCL  header  segment  is  created  in  the  BCL  data  base  by  the  BCL  manager  trans¬ 
action.  It  is  under  this  header  segment  that  the  system's  BCL  will  exist  when  its  build  occurs. 
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